Записки о виртуализации и о жизни
В VMware vSphere 7.0 появился новый встроенный продукт для управления обновлениями Lifecycle Manager. Кратко я о нём упоминал в статье:
Данный менеджер умеет проверять HCL и даже, по слухам, обновлять прошивки оборудования!
После несколько обращений по поводу функционала и неполным пониманием собеседников как это работает настало время написать про интеграцию с экосистемой Lenovo. Continue reading “Обновляем серверы Lenovo Thinksystem/ThinkAgile VX с помощью VMware vSphere Lifecycle Manager”
После виртуального посещения VeeamONTour 2021, решил пересмотреть доклад Никиты Козленко “10 рекомендаций для ускорения процессов резервного копирования и восстановления”.
И на совете #10 залип – оказывается, что при восстановлении тонких дисков ВМ из резервных копий через транспорт DirectSAN получаем толстые диски. А мы после полноценной поддержки vSphere’ой команды UNMAP перешли на тонкие диски.
Админы СРК и ВД знали про этот нюанс и фигачили толстые диски, так как не знали как заменить транспорт и на какой (cиняя ссылка “Pick proxy to use”). Проведя консилиум и тесты, решили при восстановление выбирать прокси с транспортом hot-add (vSphere 7, 350+52+40 ГБ):
| VBR NBD | VBR DirectSAN | VBR Hot-Add (2 теста) | Acronis (Hot-Add?) |
|---|---|---|---|
| 11:30:04 | 0:27:20 | 0:22:23/00:27:39 | 1:30:00 |
Время восстановления получилось сопоставимо с DirectSAN, при этом диски остаются тонкими.
P.S. Чё-то NBD на 10 GbE у нас медленноват…
Постоянный читатель прислал свои мысли о выборе гипервизоров и убедительной победе vSphere 7.0, несмотря на все грабли ;).
С чего все началось
Недавно у наших коллег появилось осознание, что:
Поэтому было решено:
Серверы, в основном, производства HPE и Huawei, на каких-то задачах используются серверы Supermicro. Предлагают закупать Dell, HPE, Lenovo. У Huawei сейчас все сложно, а присматриваться к линейке Kunpeng на Arm сейчас нет времени. Хотя под Arm есть и MS Server, и ESXi.
Почему ESXi, а не что-то еще Continue reading “Переход на VMware vSphere 7.0 update 2”
Мы ранее уже писали про тонкости синхронизации времени с хостом.
А сейчас речь пойдет про локальное время на хосте и опцию по синхронизации времени ВМ с хостом, появившуюся в vSphere 7.0.
Для того, чтобы узнать локальное время на сервере ESXi в часовом поясе UTC+0, можно воспользоваться следующим скриптом PowerCLI:
|
1 |
<em>Get-View -ViewType HostSystem -Property Name,ConfigManager.DateTimeSystem | sort Name | select Name,@{Name="Current VMHost Time";Expression={(Get-View $_.ConfigManager.DateTimeSystem).QueryDateTime()}}</em> |
|
1 2 3 4 5 6 7 8 9 10 |
Name Current VMHost Time ---- ------------------- esxi1.domain.ru 11.06.2021 6:58:04 esxi2.domain.ru 11.06.2021 7:28:16 esxi3.domain.ru 11.06.2021 6:58:04 esxi4.domain.ru 11.06.2021 7:23:46 esxi5.domain.ru 11.06.2021 6:58:05 esxi6.domain.ru 11.06.2021 6:58:05 |
Если захотите побольше узнать про вложенные свойства ConfigManager.DateTimeSystem, то можно воспользоваться фильтром к Get-View и параметром -ExpandProperty (ниже будет приведен пример для виртуальной машины).
Для того, чтобы узнать, синхронизирует ли свое время виртуальная машина через VMware Tools с хостом, можно воспользоваться одним из вариантов ниже.
Для vSphere 7.0U1 и выше:
|
1 |
<em>Get-View -ViewType virtualmachine | Select name,@{N='ToolsConfigInfo';E={$_.Config.Tools.syncTimeWithHostallowed }}</em> |
Для более старых версий:
|
1 |
<em>Get-View -ViewType virtualmachine | Select name,@{N='ToolsConfigInfo';E={$_.Config.Tools.syncTimeWithHost }}</em> |
Отличие 7.0U1 от более старых версий в том, что свойство SyncTimeWithHost переключает разные настройки ВМ. В новой версии появился дополнительный флаг – “Synchronize time periodically”, который отвечает за синхронизацию времени с хостом раз в 60 секунд (по умолчанию отключен).
Соответственно, свойство “SyncTimeWithHost” в 7.0.1 переключает не общую синхронизацию времени, а именно “периодическую” синхронизацию. В более старых версиях это свойство отвечает за общую синхронизацию времени, тогда как в 7.0.1 за общую синхронизацию стал отвечать параметр SyncTimeWithHostAllowed!
P.S. Для того, чтобы узнать больше о содержимом вложенного свойства, например, Config.Tools, можно воспользоваться следующим фильтром:
|
1 |
get-view -viewtype VirtualMachine -filter @{Name="vm_name"} | select -ExpandProperty config | select -ExpandProperty tools |
В VMware vCenter и VSAN обнаружены критические уязвимости – VMSA-2021-0010: What You Need to Know.
Всем клиентам рекомендовано немедленно обновиться до свежих версий ПО (хм, что же будут делать когда до z дойдут?):
Скрипт для проверки уязвимости h5-vsan через nmap доступен на гитхабе:
CVE-2021-21985 (Vulnerable Code)
P.S. PoC эксплойта тоже… ;(
Rob de Veij выпустил обновление своей отличной утилиты инвентаризации VMware vSphere — RVTools версии 4.1.2.
В этой версии появились новые функции:
Осенью 2020 года компания VMware анонсировала утилиту сбора и разбора журналов событий с vSphere 6.5, 6.7, 7.0 – VMware Skyline Health Diagnostic Tool.
Утилита довольно просто устанавливается в виде ВМ (с версии 2.0.5 распространяется в виде OVA и ISO) , после этого указывается vCenter/ESXi, выбираются объекты для сбора логов и, подождав несколько десятков минут или несколько часов, получаем отчёты с замечаниями и ссылками на БЗ VMware.
Примечание. Утилита имеет довольно убогий интерфейс – если вы вышли из админки, то не видно есть ли текущие задания. Обновление: с версии 2.5.0 отображение заданий исправлено, да и дизайн слегка причесали. Continue reading “Утилита самообслуживания VMware Skyline Health Diagnostic Tool”
Как в случае и с предыдущими релизами, компания VMware решила заранее предупредить заказчиков о прекращении поддержки процессоров в следующей платформе виртуализации VMware vSphere 7.Next.
9 марта 2021 года вышла заметка в БЗ – Updated Plan for CPU Support Discontinuation In Future Major vSphere Releases (82794), содержащая большой список процессоров Intel и AMD, при установке vSphere 7.0 update 2 на которые будет возникать предупреждение:
|
1 |
CPU_SUPPORT_WARNING: The CPUs in this host may not be supported in future ESXi releases. Please plan accordingly. |
Больше всего озадачило прекращение поддержки серий процессоров Intel Xeon E5-2600-v1/v2 и даже v3. Если первые два поколения уже довольно пожилые, то третье поколение встречается в 4-5-летних серверах. Пользователям остаётся только вариант замены Xeon E5-2600 v3 (Haswell) на v4 (Broadwell), но даже б/у оборудование стоит очень прилично – от 500 долларов за средний в линейке процессор.
Напоследок картинка с доработками аппаратной виртуализации в Broadwell и улучшениями задержек при операциях VM Enter/Exit между поколениями Xeon на базе архитектуры Core :
Этим мартом компания VMware выпустила огромное обновление своих продуктов:
Выпущено много новых заметок в базе знаний по проблемам, планам, принятым решениям по платформе VMware vSphere 7.0 Update 2:
mr_orangeV прислал заметку о решение проблемы с VMDB transport.
После обновления ESXi до версии 6.7 сборка 17499825 и вывода хоста из режима обслуживания, виртуальные машины не мигрировали обратно на хост с ошибкой:
|
1 |
Transport (VMDB) error -45: Failed to connect to peer process |
Поиск корневых причин привёл к нескольким вариантам:
Как найти реальную причину?
Для начала прочитать все, что написано в комьюнити и БЗ: ссылка 01 и ссылка 02 kb 50113127.
Во второй KB указано, что “Confirm the presence of the Unlocker installation on the ESXi host using one or more of the following commands”.
В моём случае эти команды не показали ничего, а команды ls -l /bin/vmx в kb нет.
Подключаемся к хосту по SSH и GUI, смотрим:
В моем случае, это оказался неудаленный полностью Unlocker.
Шаги решения
Материалы для внеклассного чтения Continue reading “Transport (VMDB) error -45: Failed to connect to peer process после обновления VMware ESXi”