Записки о виртуализации и о жизни
Компания VMware анонсировала vSphere&vSAN 7.0 Update 3 и опубликовала несколько материалов об этих продуктах:
И снова статья от участника телеграм-канала VMware User Group Rus.
Третьего дня в чат опять пришли коллеги с стандартной проблемой – хост отвалился от vCenter – ШТО ДЕЛАТЬ?
Правильный ответ – писать сценарии отказа и отрабатывать их, это один из таких случаев, с которыми надо быть знакомыми до начала эксплуатации.
Есть некий хост с VMware (разумеется, с последними патчами – а то было тут как-то PR 2412475: You see Sensor -1 type hardware health alarms on ESXi hosts and receive excessive mail alerts). Хост отвалился от VCenter (разумеется, тоже с последними патчами – особенно это касается линейки 7.0). Виртуальные машины на хосте продолжают работать, отказоустойчивости на уровне сервисов (Oracle real application clusters, database availability group, MS SQL Always On и так далее) нет, но и просто так перезагрузить хост – не вариант. Нет никаких гарантий, что хост поднимется, что есть ресурсы на других хостах.
В данном случае имеет смысл обратиться в поддержку – если, конечно, у вас система работает на поддерживаемой конфигурации, куплены лицензии и куплена эта самая поддержка. Поддержку можно купить «поштучно» – VMware Per Incident Support.
Continue reading “Падучая ESXi или возвращение блудного хоста”
Компания VMware реализовала поддержку графических API DirectX 11 и OpenGL 4.1 в виртуальных машинах в следующих своих продуктах:
Почему не бьются версии vHW выяснить не удалось.
Новый функционал может быть интересен для поддержки 3D в средах VDI в режиме VSGA (HCL): Continue reading “Поддержка API DirectX 11 и OpenGL 4.1 в виртуальных машинах VMware”
В 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 эксплойта тоже… ;(
Осенью 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 :
