«Альт Виртуализация» — это российское решение для построения и управления виртуальной инфраструктурой. Недавно вышедший релиз Альт Виртуализации версии 11.0 базируется на Proxmox VE 8.4 и предлагает унифицированный способ работы с виртуальными машинами (KVM/QEMU) и контейнерами (LXC) через веб-интерфейс, CLI и API. Поддерживаются архитектуры x86_64 и AArch64. Продукт включён в Реестр отечественного ПО Минцифры (рег.№ 6487) и выпускается в редакционном формате: сейчас доступна только PVE-версия, облачная готовится.

Основная функциональность продукта

1. Виртуализация серверов:

• Полноценная аппаратная виртуализация под KVM/QEMU.
• Лёгкие контейнеры LXC с поддержкой cgroups/namespaces.

2. Кластеризация и HA – обновлённая кластерная файловая система (pmxcfs), живая миграция, механизмы высокой доступности.

3. Сетевая инфраструктура – Linux bridge, Open vSwitch, VLAN, bonding, а теперь SDN с поддержкой VXLAN, QinQ и виртуальных сетей (VNets).

4. Хранилища – поддержка локальных (LVM, ZFS) и сетевых хранилищ (NFS, iSCSI, Ceph, GlusterFS и др.).

5. Резервное копирование – встроенные средства + интеграция с Proxmox Backup Server 3.3.

6. Безопасность и аутентификация – механизм ролевого доступа RBAC, поддержка PAM, LDAP, MS AD/Samba DC, OpenID Connect; OpenSSL 3.3 обеспечивает повышенную безопасность.

7. Поддержка GPU/PCI passthrough – возможность напрямую передавать устройства в ВМ.

8. Интеграция и API – единый Web GUI, CLI (с автодополнением), RESTful API на JSON для внешних интеграций.

Новшества в версии Альт Виртуализация 11.0

• Быстрая установка с выбором файловых систем Ext4 или Btrfs (RAID 0/1/10), автоматическим созданием LVM-thin.
• Интегрированный сетевой раздел с поддержкой VLAN, автоматическим мостом vmbr0, DNS и доменами.

• Полная поддержка SDN: создание виртуальных сетевых зон, сегментаций, изоляции, VNets и управление трафиком.

• Из веб-интерфейса можно подключать и отключать репозитории, обновлять систему и пакеты без CLI.

• Контейнеризация на базе Kubernetes, Docker, CRI-O, Podman вынесена в «Альт Сервер 11.0», что позволило повысить стабильность и упрощённость PVE-системы.
• Для виртуализации остался только LXC.

5. Импорт из VMware ESXi

• Новый инструмент упрощает миграцию: импортирует VMDK + конфигурации сети и дисков напрямую из ESXi.

6. Обновление компонентов

• Основные версии: PVE 8.4, LXC 6.0, QEMU 9.2, Ceph 19.2, Open vSwitch 3.3, Corosync 3.1, ZFS 2.3, OpenSSL 3.3.

Зачем всё это нужно

• Быстрая и простая установка снижает порог входа и риски ошибок.
• SDN-поддержка позволяет строить сложную и безопасную сетевую инфраструктуру без стороннего ПО.
• Гибкое обновление через GUI упрощает эксплуатацию.
• Упрощённая среда без лишних контейнерных инструментов — более надёжна и менее уязвима.
• Прямая миграция с VMware облегчает переход на отечественные решения.
• Современные компоненты поднимают производительность, безопасность и совместимость.

Заключение

«Альт Виртуализация 11.0» — важный шаг вперёд для российской виртуализации. Упрощённая установка, расширенные сетевые возможности, интеграция с системами резервного копирования и удобное обновление делают платформу достойным решением для корпоративного уровня. Первоначальный фокус на PVE-редакции с дальнейшим выходом облачной версии обеспечит гибкость и масштабируемость.

В условиях ухода западных вендоров с российского рынка и активного импортозамещения, спрос на отечественные платформы виртуализации значительно вырос. Одним из наиболее ярких и амбициозных проектов в этой области является «Иридиум», решение компании РТ-Иридиум, предназначенное для построения отказоустойчивой и масштабируемой виртуальной инфраструктуры. В июле 2025 года был представлен релиз «Иридиум» 2.0, вобравший в себя широкий набор корпоративных функций.

Архитектура и технологическая база

Платформа «Иридиум» построена на базе гипервизора KVM/QEMU — проверенного временем решения с открытым исходным кодом, которое активно используется и в других коммерческих продуктах (в том числе в ROSA Virtualization и Proxmox). Использование KVM обеспечивает высокую производительность, гибкость, поддержку современных функций виртуализации, а также совместимость с отечественным оборудованием.

Компоненты архитектуры «Иридиум»:

• Гипервизор: KVM (работает на Linux, взаимодействует с аппаратной виртуализацией через Intel VT-x/AMD-V).
• Управляющая панель: web-интерфейс с ролью диспетчера и оркестратора (аналог vCenter).
• VSAN-подобное хранилище: поддержка отказоустойчивого кластера хранения.
• Система управления пользователями и политиками безопасности (в том числе LDAP, SSO).
• Интеграция с Docker-контейнерами — что делает платформу применимой не только для ВМ, но и для микросервисных архитектур.
• Кластеры высокой доступности — объединение до 64 физических узлов с горячей миграцией и автоматическим восстановлением ВМ.

Новые возможности в версии 2.0

Релиз «Иридиум» 2.0 вывел продукт на уровень зрелого корпоративного решения. В числе ключевых новшеств:

• HA-кластеры (High Availability) — автоматическое восстановление ВМ при сбое узла.
• Горячая и холодная миграция виртуальных машин между узлами.
• Встроенное резервное копирование и восстановление.
• Поддержка VDI-сценариев (виртуальных рабочих столов).
• Контроль доступа и кросс-доменная авторизация.
• Новая панель мониторинга с метриками и журналами аудита.
• Совместимость с российскими серверами (например, RDW Computers), включая проверку отказоустойчивости.

Сравнение с конкурентами

Заключение

С выходом версии 2.0 платформа «Иридиум» совершила качественный скачок, превратившись в конкурентоспособную альтернативу западным решениям уровня VMware. Поддержка кластеров высокой доступности, встроенное резервное копирование, интерфейс управления и интеграция с VDI делают продукт особенно привлекательным для корпоративных клиентов, органов власти и критически важных объектов инфраструктуры.

Благодаря открытому гипервизору KVM, российской разработке, масштабируемости и активной интеграции с отечественным «железом», «Иридиум» становится не просто ответом на уход VMware, но полноценным участником новой экосистемы российских ИТ-решений.

Более подробно о продукте можно узнать тут.

ROSA Virtualization — это отечественная платформа для управления виртуальной серверной инфраструктурой, разработанная АО «НТЦ ИТ РОСА». Она построена на базе открытого программного обеспечения (KVM, libvirt и др.) и предназначена для развёртывания отказоустойчивых, масштабируемых и защищённых виртуализованных сред.

• Создание и управление виртуальными машинами
• Настройка виртуальных сетей и хранилищ
• Кластеры высокой доступности (HA)
• Живая миграция ВМ между хостами
• Резервное копирование и восстановление
• Централизованное управление через веб-интерфейс
• Поддержка требований по безопасности и соответствие ГОСТ
• Сертификация для использования в госорганах

Главные изменения ROSA Virtualization 3.1 (релиз 27 мая 2025 года)

Теперь все операции, включая настройку LDAP, шифрование дисков и управление пользователями, доступны через единый графический интерфейс. CLI используется только в самых экстренных случаях.

Включение интеграции с распределённым хранилищем Ceph позволило значительно повысить отказоустойчивость, масштабируемость и надёжность платформы.

Поддерживается безостановочная миграция виртуальных машин между кластерами. Кроме того, при корректной перезагрузке хоста ВМ теперь автоматически запускаются после восстановления.

Добавлена визуализация сетевой схемы, мастер настройки NFS, улучшен интерфейс бэкапов (включительно поддержка СУСВ через веб), а также адаптация событий под требования ГОСТ.

Нововведения включают поддержку Loudplay (протокол для передачи консольных данных) и адаптацию событийной логики в соответствии с ГОСТ-стандартами.

Платформа доступна по одной из двух моделей лицензирования: либо по числу виртуальных машин, либо по числу хостов. В комплект входит год технической поддержки, включая версию сертифицированную ФСТЭК.

Почему это важно

• Упрощение управления: привычные интерфейсы GUI значительно снижают порог входа для операторов и системных администраторов.
• Надёжность и масштабируемость: интеграция с Ceph обеспечивает отказоустойчивую, распределённую архитектуру хранения.
• Бесшовность и доступность: живая миграция и автозапуск ВМ минимизируют время простоя.
• Безопасность и соответствие: ГОСТ-адаптация и сертификация ФСТЭК делают решение готовым к внедрению в государственных структурах и критически важной инфраструктуре.

Кому подойдёт ROSA Virtualization 3.1

• Организациям госсектора и тем, кто выполняет требования по импортозамещению и ГОСТ-сертификации.
• Компаниям, нуждающимся в простом и визуальном администрировании виртуальной инфраструктуры.
• Телеком-операторам, дата-центрам и частным компаниям, которым важна отказоустойчивость и масштабируемость.

ROSA Virtualization 3.1 — зрелое отечественное решение для виртуализации, сочетающее:

• Простоту и удобство графического интерфейса
• Корпоративную надёжность благодаря Ceph и живой миграции
• Соответствие государственным стандартам безопасности.

Платформа отлично подходит для предприятий и госструктур, где нужна надёжная, масштабируемая и управляемая виртуальная инфраструктура отечественного производства.

По умолчанию скорость соединения (link speed) адаптера vmxnet3 виртуальной машины устанавливается как 10 Гбит/с. Это применяемое по умолчанию отображаемое значение в гостевой ОС для соединений с любой скоростью. Реальная скорость будет зависеть от используемого вами оборудования (сетевой карты).

VMXNET 3 — это паравиртуализированный сетевой адаптер, разработанный для обеспечения высокой производительности. Он включает в себя все функции, доступные в VMXNET 2, и добавляет несколько новых возможностей, таких как поддержка нескольких очередей (также известная как Receive Side Scaling в Windows), аппаратное ускорение IPv6 и доставка прерываний с использованием MSI/MSI-X. VMXNET 3 не связан с VMXNET или VMXNET 2.

Если вы выведите свойства соединения на адаптере, то получите вот такую картину:

В статье Broadcom KB 368812 рассказывается о том, как с помощью расширенных настроек виртуальной машины можно установить корректную скорость соединения. Для этого выключаем ВМ, идем в Edit Settings и на вкладке Advanced Parameters добавляем нужное значение:

ethernet0.linkspeed    20000

Также вы можете сделать то же самое, просто добавив в vmx-файл виртуальной машины строчку ethernetX.linkspeed = "ХХХ".

При этом учитывайте следующие моменты:

• Начиная с vSphere 8.0.2 и выше, vmxnet3 поддерживает скорость соединения в диапазоне от 10 Гбит/с до 65 Гбит/с.
• Значение скорости по умолчанию — 10 Гбит/с.
• Если вами указано значение скорости меньше 10000, то оно автоматически устанавливается в 10 Гбит/с.
• Если вами указано значение больше 65000, скорость также будет установлена по умолчанию — 10 Гбит/с.

Важно отметить, что это изменение касается виртуального сетевого адаптера внутри гостевой операционной системы виртуальной машины и не влияет на фактическую скорость сети, которая всё равно будет ограничена физическим оборудованием (процессором хоста, физическими сетевыми картами и т.д.).

Это изменение предназначено для обхода ограничений на уровне операционной системы или приложений, которые могут возникать из-за того, что адаптер vmxnet3 по умолчанию определяется со скоростью 10 Гбит/с.

В видеоролике ниже рассматривается то, как включить Virtualization-Based Security (VBS) в гостевых операционных системах Windows, работающих в среде VMware Cloud Foundation и vSphere:

Что такое Virtualization-Based Security (VBS)?

VBS — это технология безопасности от Microsoft, использующая возможности аппаратной виртуализации и изоляции для создания защищённой области памяти. Она используется для защиты критически важных компонентов операционной системы, таких как Credential Guard и Device Guard.

Предварительные требования

Перед тем как включить VBS, необходимо убедиться в выполнении следующих условий:

1. Active Directory Domain Controller
   Необходим для настройки групповой политики. В демонстрации он уже создан, но пока выключен.

2. Загрузка через UEFI (EFI)
   Виртуальная машина должна использовать загрузку через UEFI, а не через BIOS (legacy mode).

3. Secure Boot
   Желательно включить Secure Boot — это обеспечивает дополнительную защиту от вредоносных программ на стадии загрузки.

4. Модуль TPM (Trusted Platform Module)
   Не обязателен, но настоятельно рекомендуется. Большинство руководств по безопасности требуют его наличия.

Настройка VBS в VMware

1. Перейдите к параметрам виртуальной машины в Edit Settings.

2. Убедитесь, что:

   • Используется UEFI и включен Secure Boot.
   • Включена опция "Virtualization-based security" в VM Options.
   • Виртуализация ввода-вывода (IO MMU) и аппаратная виртуализация будут активированы после перезагрузки.

Важно: Если переключаться с legacy BIOS на EFI, ОС может перестать загружаться — будьте осторожны.

Настройка VBS внутри Windows

После включения параметров на уровне гипервизора нужно активировать VBS в самой Windows:

1. Запустите gpedit.msc (Редактор локальной групповой политики).

2. Перейдите по пути:

   Administrative Templates > System > Device Guard 

3. Включите следующие параметры:
   • Turn on Virtualization Based Security – активировать.
   • Secure Boot and DMA Protection – да.
   • Virtualization-based protection of Code Integrity – включить с UEFI Lock.
   • Credential Guard – включить.
   • Secure Launch Configuration – включить.

Примечание: Если вы настраиваете контроллер домена, обратите внимание, что Credential Guard не защищает базу данных AD, но защищает остальную ОС.

4. Перезагрузите виртуальную машину.

Проверка работоспособности VBS

После перезагрузки:

1. Откройте System Information и убедитесь, что:

• Virtualization Based Security включена.
• MA Protection работает.
• redential Guard активен.

2. В Windows Security проверьте:

• Включена ли Memory Integrity.
• Активна ли защита от вмешательства (Tamper Protection).

Заключение

Теперь у вас есть полностью защищённая Windows-гостевая ОС с включённой Virtualization-Based Security, Credential Guard и другими функциями. Это отличный способ повысить уровень безопасности в вашей инфраструктуре VMware.

Для получения дополнительной информации смотрите ссылки под видео.

Пару лет назад Дункан Эппинг писал о функции Witness Resilience - это функция повышения устойчивости к сбоям свидетеля (Witness Failure Resilience) в конфигурациях растянутых кластеров vSAN 7.0 Update 3 (stretched clusters). Эта функция направлена на обеспечение доступности виртуальных машин даже при одновременном выходе из строя одного из дата-центров и узла-свидетеля (Witness). Мы ее детально описывали вот тут.

В традиционной конфигурации растянутого кластера данные реплицируются между двумя сайтами, а узел-свидетель размещается в третьей локации для обеспечения кворума. При отказе одного из сайтов кворум сохраняется за счет оставшегося сайта и узла-свидетеля. Однако, если после этого выходит из строя узел-свидетель, оставшийся сайт терял кворум, что приводило к недоступности машин.

С введением функции устойчивости к сбоям свидетеля в vSAN 7.0 Update 3, при отказе одного из сайтов система автоматически перераспределяет голоса (votes) компонентов данных. Компоненты на оставшемся сайте получают дополнительные голоса, а голоса компонентов на узле-свидетеле — уменьшаются. Это означает, что если после отказа сайта выходит из строя и узел-свидетель, оставшийся сайт все еще имеет достаточное количество голосов для поддержания кворума и обеспечения доступности ВМ.

Важно отметить, что процесс перераспределения голосов занимает некоторое время (обычно около 3 минут), в течение которого система адаптируется к новой конфигурации. После восстановления отказавшего сайта и узла-свидетеля система возвращает исходное распределение голосов для нормальной работы.

Таким образом, функция устойчивости к сбоям свидетеля значительно повышает надежность и отказоустойчивость растянутых кластеров, позволяя ВМ оставаться доступными даже при одновременном отказе одного из сайтов и узла-свидетеля.

Недавно Дункан снова поднял тонкий вопрос на эту тему. Он провёл несколько тестов и решил написать продолжение прошлой статьи. В данном случае мы говорим о конфигурации с двумя узлами, но это также применимо и к растянутому кластеру (stretched cluster).

В случае растянутого кластера или конфигурации с двумя узлами, когда сайт с данными выходит из строя (или переводится в режим обслуживания), автоматически выполняется перерасчёт голосов для каждого объекта/компонента. Это необходимо для того, чтобы при последующем выходе из строя Witness объекты/виртуальные машины оставались доступными.

А что если сначала выйдет из строя Witness, а только потом сайт с данными?

Это объяснить довольно просто — в таком случае виртуальные машины станут недоступными. Почему? Потому что в этом сценарии перерасчёт голосов уже не выполняется. Конечно же, он протестировал это, и ниже представлены скриншоты, которые это подтверждают.

На этом скриншоте показано, что Witness отсутствует (Absent), и оба компонента с данными имеют по одному голосу. Это значит, что если один из хостов выйдет из строя, соответствующий компонент станет недоступным. Давайте теперь отключим один из хостов и посмотрим, что покажет интерфейс.

Как видно на скриншоте ниже, виртуальная машина теперь недоступна. Это произошло из-за того, что больше нет кворума — 2 из 3 голосов недействительны:

Это говорит нам о том, что нужно обязательно следить за доступностью хоста Witness, который очень важен для контроля кворума кластера.

Компания VMware в марте обновила технический документ под названием «VMware vSphere 8.0 Virtual Topology - Performance Study» (ранее мы писали об этом тут). В этом исследовании рассматривается влияние использования виртуальной топологии, впервые представленной в vSphere 8.0, на производительность различных рабочих нагрузок. Виртуальная топология (Virtual Topology) упрощает назначение процессорных ресурсов виртуальной машине, предоставляя соответствующую топологию на различных уровнях, включая виртуальные сокеты, виртуальные узлы NUMA (vNUMA) и виртуальные кэши последнего уровня (last-level caches, LLC). Тестирование показало, что использование виртуальной топологии может улучшить производительность некоторых типичных приложений, работающих в виртуальных машинах vSphere 8.0, в то время как в других случаях производительность остается неизменной.

Настройка виртуальной топологии

В vSphere 8.0 при создании новой виртуальной машины с совместимостью ESXi 8.0 и выше функция виртуальной топологии включается по умолчанию. Это означает, что система автоматически настраивает оптимальное количество ядер на сокет для виртуальной машины. Ранее, до версии vSphere 8.0, конфигурация по умолчанию предусматривала одно ядро на сокет, что иногда приводило к неэффективности и требовало ручной настройки для достижения оптимальной производительности.

Влияние на производительность различных рабочих нагрузок

• Базы данных: Тестирование с использованием Oracle Database на Linux и Microsoft SQL Server на Windows Server 2019 показало улучшение производительности при использовании виртуальной топологии. Например, в случае Oracle Database наблюдалось среднее увеличение показателя заказов в минуту (Orders Per Minute, OPM) на 8,9%, достигая максимума в 14%.

• Инфраструктура виртуальных рабочих столов (VDI): При тестировании с использованием инструмента Login VSI не было зафиксировано значительных изменений в задержке, пропускной способности или загрузке процессора при включенной виртуальной топологии. Это связано с тем, что создаваемые Login VSI виртуальные машины имеют небольшие размеры, и виртуальная топология не оказывает значительного влияния на их производительность.

• Тесты хранилищ данных: При использовании бенчмарка Iometer в Windows наблюдалось увеличение использования процессора до 21% при включенной виртуальной топологии, несмотря на незначительное повышение пропускной способности ввода-вывода (IOPS). Анализ показал, что это связано с поведением планировщика задач гостевой операционной системы и распределением прерываний.

• Сетевые тесты: Тестирование с использованием Netperf в Windows показало увеличение сетевой задержки и снижение пропускной способности при включенной виртуальной топологии. Это связано с изменением схемы планирования потоков и прерываний сетевого драйвера, что приближает поведение виртуальной машины к работе на физическом оборудовании с аналогичной конфигурацией.

Рекомендации

В целом, виртуальная топология упрощает настройки виртуальных машин и обеспечивает оптимальную конфигурацию, соответствующую физическому оборудованию. В большинстве случаев это приводит к улучшению или сохранению уровня производительности приложений. Однако для некоторых микробенчмарков или специфических рабочих нагрузок может наблюдаться снижение производительности из-за особенностей гостевой операционной системы или архитектуры приложений. В таких случаях рекомендуется либо использовать предыдущую версию оборудования, либо вручную устанавливать значение «ядер на сокет» равным 1.

Для получения более подробной информации и рекомендаций по настройке виртуальной топологии в VMware vSphere 8.0 рекомендуется ознакомиться с полным текстом технического документа.

Интересный пост, касающийся использования виртуальных хранилищ NFS (в формате Virtual Appliance) на платформе vSphere и их производительности, опубликовал Marco Baaijen в своем блоге. До недавнего времени он использовал центральное хранилище Synology на основе NFSv3 и две локально подключенные PCI флэш-карты. Однако из-за ограничений драйверов он был вынужден использовать ESXi 6.7 на одном физическом хосте (HP DL380 Gen9). Желание перейти на vSphere 8.0 U3 для изучения mac-learning привело тому, что он больше не мог использовать флэш-накопители в качестве локального хранилища для размещения вложенных виртуальных машин. Поэтому Марко решил использовать эти флэш-накопители на отдельном физическом хосте на базе ESXi 6.7 (HP DL380 G7).

Теперь у нас есть хост ESXi 8 и и хост с версией ESXi 6.7, которые поддерживают работу с этими флэш-картами. Кроме того, мы будем использовать 10-гигабитные сетевые карты (NIC) на обоих хостах, подключив порты напрямую. Марко начал искать бесплатное, удобное и функциональное виртуальное NAS-решение. Рассматривал Unraid (не бесплатный), TrueNAS (нестабильный), OpenFiler/XigmaNAS (не тестировался) и в итоге остановился на OpenMediaVault (с некоторыми плагинами).

И вот тут начинается самое интересное. Как максимально эффективно использовать доступное физическое и виртуальное оборудование? По его мнению, чтение и запись должны происходить одновременно на всех дисках, а трафик — распределяться по всем доступным каналам. Он решил использовать несколько паравиртуальных SCSI-контроллеров и настроить прямой доступ (pass-thru) к портам 10-гигабитных NIC. Всё доступное пространство флэш-накопителей представляется виртуальной машине как жесткий диск и назначается по круговому принципу на доступные SCSI-контроллеры.

В OpenMediaVault мы используем плагин Multiple-device для создания страйпа (striped volume) на всех доступных дисках.

На основе этого мы можем создать файловую систему и общую папку, которые в конечном итоге будут представлены как экспорт NFS (v3/v4.1). После тестирования стало очевидно, что XFS лучше всего подходит для виртуальных нагрузок. Для NFS Марко решил использовать опции async и no_subtree_check, чтобы немного увеличить скорость работы.

Теперь переходим к сетевой части, где автор стремился использовать оба 10-гигабитных порта сетевых карт (X-соединённых между физическими хостами). Для этого он настроил следующее в OpenMediaVault:

С этими настройками серверная часть NFS уже работает. Что касается клиентской стороны, Марко хотел использовать несколько сетевых карт (NIC) и порты vmkernel, желательно на выделенных сетевых стэках (Netstacks). Однако, начиная с ESXi 8.0, VMware решила отказаться от возможности направлять трафик NFS через выделенные сетевые стэки. Ранее для этого необходимо было создать новые стэки и настроить SunRPC для их использования. В ESXi 8.0+ команды SunRPC больше не работают, так как новая реализация проверяет использование только Default Netstack.

Таким образом, остаётся использовать возможности NFS 4.1 для работы с несколькими соединениями (parallel NFS) и выделения трафика для портов vmkernel. Но сначала давайте посмотрим на конфигурацию виртуального коммутатора на стороне NFS-клиента. Как показано на рисунке ниже, мы создали два раздельных пути, каждый из которых использует выделенный vmkernel-порт и собственный физический uplink-NIC.

Первое, что нужно проверить, — это подключение между адресами клиента и сервера. Существуют три способа сделать это: от простого до более детального.

[root@mgmt01:~] esxcli network ip interface list
---
vmk1
   Name: vmk1
   MAC Address: 00:50:56:68:4c:f3
   Enabled: true
   Portset: vSwitch1
   Portgroup: vmk1-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 134217815

vmk2
   Name: vmk2
   MAC Address: 00:50:56:6f:d0:15
   Enabled: true
   Portset: vSwitch2
   Portgroup: vmk2-NFS
   Netstack Instance: defaultTcpipStack
   VDS Name: N/A
   VDS UUID: N/A
   VDS Port: N/A
   VDS Connection: -1
   Opaque Network ID: N/A
   Opaque Network Type: N/A
   External ID: N/A
   MTU: 9000
   TSO MSS: 65535
   RXDispQueue Size: 4
   Port ID: 167772315

[root@mgmt01:~] esxcli network ip netstack list defaultTcpipStack
   Key: defaultTcpipStack
   Name: defaultTcpipStack
   State: 4660

[root@mgmt01:~] ping 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.219 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.173 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.174 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.173/0.189/0.219 ms

[root@mgmt01:~] ping 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.155 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.141 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.187 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.161/0.187 ms

root@mgmt01:~] vmkping -I vmk1 10.10.10.62
PING 10.10.10.62 (10.10.10.62): 56 data bytes
64 bytes from 10.10.10.62: icmp_seq=0 ttl=64 time=0.141 ms
64 bytes from 10.10.10.62: icmp_seq=1 ttl=64 time=0.981 ms
64 bytes from 10.10.10.62: icmp_seq=2 ttl=64 time=0.183 ms

--- 10.10.10.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.141/0.435/0.981 ms

[root@mgmt01:~] vmkping -I vmk2 172.16.0.62
PING 172.16.0.62 (172.16.0.62): 56 data bytes
64 bytes from 172.16.0.62: icmp_seq=0 ttl=64 time=0.131 ms
64 bytes from 172.16.0.62: icmp_seq=1 ttl=64 time=0.187 ms
64 bytes from 172.16.0.62: icmp_seq=2 ttl=64 time=0.190 ms

--- 172.16.0.62 ping statistics ---
3 packets transmitted, 3 packets received, 0% packet loss
round-trip min/avg/max = 0.131/0.169/0.190 ms

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk1 -H 10.10.10.62
   Trace: 
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 139 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 180 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 10.10.10.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 148 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 10.10.10.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 139 us
         Round-trip Avg: 155 us
         Round-trip Max: 180 us

[root@mgmt01:~] esxcli network diag ping --netstack defaultTcpipStack -I vmk2 -H 172.16.0.62
   Trace: 
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 0
         TTL: 64
         Round-trip Time: 182 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 1
         TTL: 64
         Round-trip Time: 136 us
         Dup: false
         Detail: 
      
         Received Bytes: 64
         Host: 172.16.0.62
         ICMP Seq: 2
         TTL: 64
         Round-trip Time: 213 us
         Dup: false
         Detail: 
   Summary: 
         Host Addr: 172.16.0.62
         Transmitted: 3
         Received: 3
         Duplicated: 0
         Packet Lost: 0
         Round-trip Min: 136 us
         Round-trip Avg: 177 us
         Round-trip Max: 213 us

С этими положительными результатами мы теперь можем подключить NFS-ресурс, используя несколько подключений на основе vmk, и убедиться, что всё прошло успешно.

[root@mgmt01:~] esxcli storage nfs41 add --connections=8 --host-vmknic=10.10.10.62:vmk1,172.16.0.62:vmk2 --share=/fio-folder --volume-name=fio

[root@mgmt01:~] esxcli storage nfs41 list
Volume Name  Host(s)                  Share        Vmknics    Accessible  Mounted  Connections  Read-Only  Security   isPE  Hardware Acceleration
-----------  -----------------------  -----------  ---------  ----------  -------  -----------  ---------  --------  -----  ---------------------
fio          10.10.10.62,172.16.0.62  /fio-folder  vmk1,vmk2        true     true            8      false  AUTH_SYS  false  Not Supported

[root@mgmt01:~] esxcli storage nfs41 param get -v all
Volume Name  MaxQueueDepth  MaxReadTransferSize  MaxWriteTransferSize  Vmknics    Connections
-----------  -------------  -------------------  --------------------  ---------  -----------
fio             4294967295               261120                261120  vmk1,vmk2            8

Наконец, мы проверяем, что оба подключения действительно используются, доступ к дискам осуществляется равномерно, а производительность соответствует ожиданиям (в данном тесте использовалась миграция одной виртуальной машины с помощью SvMotion). На стороне NAS-сервера Марко установил net-tools и iptraf-ng для создания приведённых ниже скриншотов с данными в реальном времени. Для анализа производительности флэш-дисков на физическом хосте использовался esxtop.

root@openNAS:~# netstat | grep nfs
tcp        0    128 172.16.0.62:nfs         172.16.0.60:623         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:617         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:616         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:621         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:613         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:620         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:610         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:611         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:615         ESTABLISHED
tcp        0    128 172.16.0.62:nfs         172.16.0.60:619         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:609         ESTABLISHED
tcp        0    128 10.10.10.62:nfs         10.10.10.60:614         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:618         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:622         ESTABLISHED
tcp        0      0 172.16.0.62:nfs         172.16.0.60:624         ESTABLISHED
tcp        0      0 10.10.10.62:nfs         10.10.10.60:612         ESTABLISHED

По итогам тестирования NFS на ESXi 8 Марко делает следующие выводы:

• NFSv4.1 превосходит NFSv3 по производительности в 2 раза.
• XFS превосходит EXT4 по производительности в 3 раза (ZFS также был протестирован на TrueNAS и показал отличные результаты при последовательных операциях ввода-вывода).
• Клиент NFSv4.1 в ESXi 8.0+ не может быть привязан к выделенному/отдельному сетевому стэку (Netstack).
• Использование нескольких подключений NFSv4.1 на основе выделенных портов vmkernel работает очень эффективно.
• Виртуальные NAS-устройства демонстрируют хорошую производительность, но не все из них стабильны (проблемы с потерей NFS-томов, сообщения об ухудшении производительности NFS, увеличении задержек ввода-вывода).

В прошлом году Вильям Лам продемонстрировал метод настройки строки железа SMBIOS с использованием Nested ESXi, но решение было далеко от идеала: оно требовало модификации ROM-файла виртуальной машины и ограничивалось использованием BIOS-прошивки для машины Nested ESXi, в то время как поведение с EFI-прошивкой отличалось.

В конце прошлого года Вильям проводил исследования и наткнулся на гораздо более изящное решение, которое работает как для физического, так и для виртуального ESXi. Существует параметр ядра ESXi, который можно переключить, чтобы просто игнорировать стандартный SMBIOS оборудования, а затем эмулировать собственную пользовательскую информацию SMBIOS.

Итак, давайте попробуем задать кастомные аппаратные настройки SMBIOS.

Шаг 1 – Подключитесь по SSH к вашему ESXi-хосту, отредактируйте файл конфигурации /bootbank/boot.cfg и добавьте ignoreHwSMBIOSInfo=TRUE в строку kernelopt, после чего перезагрузите систему.

Шаг 2 – Далее нам нужно выполнить команду vsish, чтобы настроить желаемую информацию SMBIOS. Однако, вместо того чтобы заставлять пользователей вручную создавать команду, Вильям создал простую функцию PowerShell, которая сделает процесс более удобным.

Сохраните или выполните приведенный ниже фрагмент PowerShell-кода, который определяет новую функцию Generate-CustomESXiSMBIOS. Эта функция принимает следующие шесть аргументов:

• Uuid – UUID, который будет использоваться в симулированной информации SMBIOS.
• Model – название модели.
• Vendor – наименование производителя.
• Serial – серийный номер.
• SKU – идентификатор SKU.
• Family – строка семейства.

Function Generate-CustomESXiSMBIOS {
    param(
        [Parameter(Mandatory=$true)][String]$Uuid,
        [Parameter(Mandatory=$true)][String]$Model,
        [Parameter(Mandatory=$true)][String]$Vendor,
        [Parameter(Mandatory=$true)][String]$Serial,
        [Parameter(Mandatory=$true)][String]$SKU,
        [Parameter(Mandatory=$true)][String]$Family
    )

    $guid = [Guid]$Uuid

    $guidBytes = $guid.ToByteArray()
    $decimalPairs = foreach ($byte in $guidBytes) {
        "{0:D2}" -f $byte
    }
    $uuidPairs = $decimalPairs -join ', '

    Write-Host -ForegroundColor Yellow "`nvsish -e set /hardware/bios/dmiInfo {\`"${Model}\`", \`"${Vendor}\`", \`"${Serial}\`", [${uuidPairs}], \`"1.0.0\`", 6, \`"SKU=${SKU}\`", \`"${Family}\`"}`n"
}

Вот пример использования функции для генерации команды vsish:

Generate-CustomESXiSMBIOS -Uuid "43f32ef6-a3a8-44cb-9137-31cb4c6c520a" -Model "WilliamLam HAL9K" -Vendor "WilliamLam.com" -Serial "HAL-9000" -SKU "H9K" -Family "WilliamLam"

Шаг 3 – После того как вы получите сгенерированную команду, выполните её на вашем хосте ESXi, как показано на скриншоте ниже:

vsish -e set /hardware/bios/dmiInfo {\"WilliamLam HAL9K\", \"WilliamLam.com\", \"HAL-9000\", [246, 46, 243, 67, 168, 163, 203, 68, 145, 55, 49, 203, 76, 108, 82, 10], \"1.0.0\", 6, \"SKU=H9K\", \"WilliamLam\"}

Вам потребуется перезапустить службу hostd, чтобы информация стала доступной. Для этого выполните команду:

/etc/init.d/hostd restart

Если вы теперь войдете в ESXi Host Client, vCenter Server или vSphere API (включая PowerCLI), то обнаружите, что производитель оборудования, модель, серийный номер и UUID отображают заданные вами пользовательские значения, а не данные реального физического оборудования!

Пользовательский SMBIOS не сохраняется после перезагрузки, поэтому вам потребуется повторно запускать команду каждый раз после перезагрузки вашего хоста ESXi.

Не все виртуальные машины на базе vSphere одинаковы, Вильям Лам написал интересный пост об обнаружении ВМ разного типа с помощью PowerCLI. Это особенно актуально с введением vSphere IaaS (ранее известного как vSphere Supervisor, vSphere with Tanzu или Project Pacific), который включает современный способ развертывания традиционных/классических виртуальных машин, а также новый тип виртуальной машины, основанный на контейнерах, известный как vSphere Pod VM.

vSphere Pod - это эквивалент Kubernetes pod в среде VMware Tanzu / vSphere IaaS. Это легковесная виртуальная машина, которая запускает один или несколько контейнеров на базе Linux. Каждый vSphere Pod точно настроен для работы с конкретной нагрузкой и имеет явно указанные reservations для ресурсов этой нагрузки. Он выделяет точное количество хранилища, памяти и процессорных ресурсов, необходимых для работы нагрузки внутри ВМ. vSphere Pods поддерживаются только в случаях, когда компонент Supervisor настроен с использованием NSX в качестве сетевого стека.

Недавно возник вопрос о том, как можно различать традиционные/классические виртуальные машины, созданные через пользовательский интерфейс или API vSphere, и виртуальные машины vSphere Pod средствами PowerCLI, в частности с использованием стандартной команды Get-VM.

Как видно на приведенном выше скриншоте, vSphere может создавать и управлять несколькими типами виртуальных машин, от традиционных/классических, которые мы все знаем последние два десятилетия, специализированных "Сервисных/Агентских" виртуальных машин, управляемых различными решениями VMware или сторонних разработчиков, и до новых виртуальных машин vSphere IaaS и виртуальных машин рабочих нагрузок контейнеров vSphere Pod (которые можно назвать Supervisor VM и Supervisor Pod VM).

Хотя команда Get-VM не различает эти типы виртуальных машин, существует несколько свойств, которые можно использовать в vSphere API для различения этих типов виртуальных машин. Ниже приведен фрагмент кода PowerCLI, который Вильям написал для того, чтобы различать типы виртуальных машин, что может быть полезно для автоматизации и/или отчетности.

$vms = Get-Vm

$results = @()
foreach ($vm in $vms) {
    if($vm.GuestId -eq "crxPod1Guest" -or $vm.GuestId -eq "crxSys1Guest") {
        $vmType = "Supervisor Pod VM"
    } elseif($vm.ExtensionData.Config.ManagedBy -ne $null) {
        switch($vm.ExtensionData.Config.ManagedBy.ExtensionKey) {
            "com.vmware.vim.eam" {$vmType = "EAM Managed VM"}
            "com.vmware.vcenter.wcp" {$vmType = "Supervisor VM"}
            "default" {$vmType = "Other 2nd/3rd Party Managed Classic VM"}
        }
    } else {
        $vmType = "Classic VM"
    }

    $tmp = [pscustomobject] @{
        Name = $vm.Name
        Type = $vmType
    }
    $results+=$tmp
}

$results | FT | Sort-Object -Property Types

Вот пример вывода скрипта для той же среды, что и на скриншоте из пользовательского интерфейса vSphere, но теперь у вас есть способ различать различные типы виртуальных машин, управляемых платформой vSphere.

В обеих версиях Microsoft Windows 10 и 11 безопасность на основе виртуализации (Virtualization Based Security, VBS) включена по умолчанию, и эта функция использует платформу Hyper-V, которая реализует технологию вложенной виртуализации (Nested Virtualization). Недавно Вильям Лам написал о том, что в связи с этим платформа VMware Workstation может выдавать ошибку.

Если вы попытаетесь запустить вложенную виртуальную машину с гипервизором ESXi в рамках Workstation под Windows, вы, скорее всего, увидите одно из следующих сообщений об ошибке в зависимости от производителя процессора:

• Virtualized Intel VT-x/EPT is not supported on this platform 
• Virtualized AMD-V/RVI is not supported on this platform 

Выглядит это так:

В то же время VMware Workstation была улучшена для совместной работы с Hyper-V благодаря новому режиму Host VBS Mode, представленному в VMware Workstation версии 17.x:

Workstation Pro uses a set of newly introduced Windows 10 features (Windows Hypervisor Platform) that permits the use of VT/AMD-V features, which enables Workstation Pro and Hyper-V to coexist. And because VBS is built on Hyper-V, Windows hosts with VBS enabled can now power on VM in Workstation Pro successfully

В документации VMware Workstation упоминаются несколько ограничений данной возможности. Тем не менее, если вам необходимо запустить вложенный ESXi под VMware Workstation, вам просто нужно отключить VBS в Windows, при условии, что у вас есть права администратора на вашем компьютере.

Шаг 1. Перейдите в раздел «Безопасность устройства» и в разделе «Основная изоляция» (Core isolation) отключите параметр «Целостность памяти» (Memory integrity), как показано на скриншоте ниже.

Шаг 2. Перезагрузите компьютер, чтобы изменения вступили в силу.

Шаг 3. Чтобы убедиться, что VBS действительно отключен, откройте Microsoft System Information (Системную информацию) и найдите запись «Безопасность на основе виртуализации» (Virtualization-based security). Убедитесь, что там указано «Не включено» (Not enabled). На устройствах, управляемых корпоративными системами, эта настройка может автоматически включаться снова. Таким образом, это поможет подтвердить, включена ли настройка или отключена.

Шаг 4. Как видно на скриншоте ниже, Вильяму удалось успешно запустить вложенный ESXi 6.0 Update 3 на последней версии VMware Workstation 17.6.2 под управлением Windows 11 22H2.

На портале технических ресурсов Broadcom появилась полезная статья, посвященная производительности облачных приложений и причинам их земедления в производственной среде.

Часто бывает, что приложение, работающее на физическом сервере, демонстрирует хорошую производительность. Однако после упаковки приложения в образ, тестирования в Docker/Podman и последующей миграции в окружение Kubernetes производительность резко падает. По мере увеличения числа запросов к базе данных, выполняемых приложением, время отклика приложения возрастает.

Эта распространённая ситуация часто вызвана задержками ввода-вывода, связанными с передачей данных. Представьте, что это же приложение снова запускается на физическом сервере, но в следующем сценарии: устройство хранения базы данных создаётся на удалённом хранилище с Network File System (NFS).

Это означает, что необходимо учитывать следующие факторы:

• Количество приложений, обращающихся к конечной точке хранилища (предполагается, что оно быстрое по своему устройству).
  Это будет влиять на общую производительность отклика из-за производительности подсистемы ввода-вывода хранилища.

• Способ, которым приложение извлекает данные из базы данных.
  Кэширует ли оно данные, или просто отправляет очередной запрос? Являются ли запросы небольшими или крупными?

• Задержка, вызванная сетевым доступом к хранилищу, и общая скорость работы хранилища.
  При доступе к сетевому устройству несколько ключевых факторов влияют на скорость передачи данных:

  • Доступная скорость соединения
  • Используемое максимальное время передачи (MTU) / максимальный размер сегмента (MSS)
  • Размер передаваемой полезной нагрузки
  • Настройки TCP окна (скользящее окно)
  • Среднее время задержки при прохождении маршрута (RTT) от точки A до точки B в мс.

В датацентре скорость соединения обычно не является проблемой, поскольку все узлы соединены с пропускной способностью не менее 1 Гбит/с, иногда 10 Гбит/с, и подключены к одному коммутатору. MTU/MSS будет оптимальным для настроенного соединения. Остаются размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT. Наибольшее влияние окажут размер полезной нагрузки, задержка соединения и его качество, которые будут влиять на параметры скользящего окна.

Вот пример задержек между узлами в текущей настройке Kubernetes:

При увеличении размера полезной нагрузки пакета в пинге, как только он превышает текущий MTU, время отклика начинает увеличиваться. Например, для node2 размер полезной нагрузки составляет 64k — это экстремальный случай, который наглядно демонстрирует рост задержки.

Учитывая эти три момента (размер передаваемой полезной нагрузки, скользящее окно TCP и среднее RTT), если разработчик создаёт приложение без использования встроенных возможностей кэширования, то запросы к базе данных начнут накапливаться, вызывая нагрузку на ввод-вывод. Такое упущение направляет все запросы через сетевое соединение, что приводит к увеличению времени отклика всего приложения.

На локальном хранилище или в среде с низкой задержкой (как сети, так и хранилища) можно ожидать, что приложение будет работать хорошо. Это типичная ситуация, когда команды разработки тестируют все в локальной среде. Однако при переходе на сетевое хранилище задержка, вызванная сетью, будет влиять на возможный максимальный уровень запросов. При проведении тех же тестов в производственной среде команды, вероятно, обнаружат, что система, способная обрабатывать, скажем, 1000 запросов к базе данных в секунду, теперь справляется только с 50 запросами в секунду. В таком случае стоит обратить внимание на три вероятные причины:

1. Переменные размеры пакетов, средний размер которых превышает настроенный MTU.
2. Сетевая задержка из-за того, что база данных размещена на отдельном узле, вдали от приложения.
3. Уменьшенное скользящее окно, так как все связанные системы подключаются к узлу базы данных. Это создаёт нагрузку на ввод-вывод файловой системы, из-за чего база данных не может обрабатывать запросы достаточно быстро.

Тесты показали, что алгоритм скользящего окна привёл к снижению скорости передачи данных (для справки: это механизм, используемый удалённым хранилищем на основе NFS). При среднем размере полезной нагрузки 4 Кб скорость передачи данных упала с 12 МБ/с на быстром соединении 1 Гбит/с (8 мс задержки) до ~15 Кбит/с, когда задержка соединения достигла 180 мс. Скользящее окно может вынудить каждую передачу данных возвращать пакет подтверждения (ACK) отправителю перед отправкой следующего пакета на соединениях с низкой задержкой.

Эту ситуацию можно протестировать локально с помощью утилиты tc на системе Linux. С её помощью можно вручную задать задержку для каждого устройства. Например, интерфейс можно настроить так, чтобы он отвечал с задержкой в 150 мс.

На Kubernetes, например, вы можете развернуть приложение с фронтендом, сервером приложений и бэкендом базы данных. Если сервер приложений и бэкенд базы данных развернуты на разных узлах, даже если эти узлы быстрые, они будут создавать сетевые задержки для каждого пакета, отправленного с сервера приложений в базу данных и обратно. Эти задержки суммируются и значительно ухудшают производительность!

Ниже приведён реальный пример, показывающий время отклика приложения. База данных развернута на node2.

В этом случае выполнение приложения требует большого количества запросов к базе данных, что значительно влияет на среднее время отклика затронутых компонентов. В данном случае среднее время отклика составляет 3,9 секунды.

Для этого теста функция graph_dyn запрашивает из базы данных 80 тысяч строк данных, где каждая строка содержит метаданные для построения различных точек графика.

Переместив базу данных на ту же машину, где размещена часть приложения, удалось снизить среднее время отклика до 0,998 секунды!

Это значительное улучшение производительности было достигнуто за счёт сокращения задержек сетевых запросов (round trip), то есть перемещения контейнера базы данных на тот же узел.

Ещё одним распространённым фактором, влияющим на производительность Kubernetes, являются ESXi-среды, где узлы кластера имеют избыточную нагрузку на ввод-вывод сети, а узлы Kubernetes развёрнуты в виде виртуальных машин. Узел Kubernetes не может увидеть, что CPU, память, ввод-вывод диска и/или подключённое удалённое хранилище уже находятся под нагрузкой. В результате пользователи сталкиваются с ухудшением времени отклика приложений.

Как оптимизировать производительность приложения

1. Учтите кэширование в дизайне приложения.
   Убедитесь, что приложение учитывает кэширование (общих запросов, запросов к базе данных и так далее) и не выполняет лишних запросов.

2. Отключите переподписку ресурсов (oversubscription) в средах ESXi.
   Если Kubernetes/OpenShift работают поверх ESXi, убедитесь, что переподписка ресурсов отключена для всех доступных CPU и памяти. Учтите, что даже небольшие задержки могут быстро накопиться и привести к эластичному поведению времени отклика приложения. Кроме того, если хост ESXi уже находится под нагрузкой, запущенные на нём образы не будут осведомлены об этом, и оркестратор Kubernetes может развернуть дополнительные поды на этом узле, считая ресурсы (CPU, память, хранилище) всё ещё доступными. Поэтому, если вы используете Kubernetes/OpenShift, а у вас есть возможность запустить их на физическом сервере, сделайте это! Вы получите прямую и полную видимость ресурсов хоста.

3. Минимизируйте сетевые задержки ввода-вывода в Kubernetes.
   Сократите сетевые задержки ввода-вывода при развёртывании подов. Упакуйте контейнеры в один под, чтобы они развертывались на одном узле. Это значительно снизит сетевые задержки ввода-вывода между сервером приложений и базой данных.

4. Размещайте контейнеры с высокими требованиями к базе данных на узлах с быстрым хранилищем.
   Развёртывайте контейнеры, которым требуется быстрый доступ к базе данных, на узлах с быстрым хранилищем. Учитывайте требования к высокой доступности и балансировке нагрузки. Если хранилище NFS недостаточно быстрое, рассмотрите возможность создания PV (Persistent Volume) на определённом узле с локальным RAID 10 диском. Учтите, что в этом случае резервирование придётся настраивать вручную, так как оркестратор Kubernetes не сможет управлять этим при отказе оборудования конкретного узла.

Как мониторить задержки между компонентами

Для Kubernetes, OpenShift и Docker (Swarm) можно использовать Universal Monitoring Agent (UMA), входящий в решения AIOps and Observability от Broadcom, для мониторинга взаимодействия всего окружения. Этот агент способен извлекать все релевантные метрики кластера. Если UMA обнаруживает поддерживаемую технологию, такую как Java, .Net, PHP или Node.js, он автоматически внедряет пробу (probe) и предоставляет детализированную информацию о выполнении приложения по запросу. Эти данные включают запросы ввода-вывода (I/O) от компонента к базе данных, удалённые вызовы и другие внутренние метрики приложения.

Если приложение работает некорректно, встроенное обнаружение аномалий UMA запускает трассировку транзакций (это не требует дополнительной настройки). UMA собирает подробные метрики с агентов, связанных с компонентами, по пути выполнения конкретного приложения. Эти возможности позволяют получить детализированное представление выполнения приложения вплоть до строки кода, вызывающей замедление. Администраторы могут настроить полный сквозной мониторинг, который предоставляет детали выполнения, включая производительность фронтенда (браузера).

Ниже приведен пример сбора полных сквозных метрик, чтобы команда администраторов могла проанализировать, что пошло не так, и при необходимости принять корректирующие меры:

User front-end => Web-Server front-end => app-server => databases | remote services

Одним из преимуществ этого решения для мониторинга является то, что оно показывает среднее время выполнения компонентов внутри кластера. Со временем решение может начать считать плохие средние значения нормой в среде ESXi с избыточной загрузкой. Тем не менее, оператор может оценить реальные значения и сравнить их с показателями других приложений, работающих на том же узле.

Broadcom сообщила, что ОС Windows Server 2025 официально сертифицирована для работы на платформе VMware vSphere версий 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3. Эти версии прошли тестирование и валидацию, обеспечивая стабильную и высокопроизводительную платформу для запуска Windows Server 2025 в качестве гостевой операционной системы в виртуальных машинах. Для получения подробной информации о поддерживаемых версиях обратитесь к Broadcom Compatibility Guide.

Что нового?

Сертификация VMware vSphere в рамках программы Microsoft SVVP

VMware vSphere 7.0 U3, 8.0, 8.0 U1, 8.0 U2 и 8.0 U3 входят в число первых гипервизоров, сертифицированных в рамках программы Microsoft Windows Server Virtualization Validation Program (SVVP). Эта сертификация подтверждает официальную поддержку Microsoft и VMware для работы Windows Server 2025 в средах VMware vSphere. Подробнее ознакомиться с сертификацией можно на странице сертификации VMware vSphere SVVP.

Поддержка VMware Tools с первого дня для Windows Server 2025

Все драйверы в режиме ядра VMware Tools полностью сертифицированы для Windows Server 2025, что обеспечивает высокую совместимость, стабильность и безопасность. Дополнительную информацию можно найти в блоге: VMware Tools 12.5.0 готов к работе с новейшими операционными системами Windows.

Драйверы VMware PVSCSI и VMXNET3 включены в Windows Server 2025

Начиная с Windows Server 2022, а теперь и для Windows Server 2025, драйверы VMware Paravirtual SCSI (PVSCSI) и сетевого адаптера VMXNET3 предустановлены в ОС от Microsoft. Это упрощает процесс настройки и обеспечивает эффективное развертывание виртуальных машин Windows Server с высокопроизводительными виртуальными устройствами без необходимости ручной установки драйверов.

Новый плагин VMXNET3 KDNET для отладки сетевого ядра

В Windows Server 2025 включён плагин расширения VMXNET3 KDNET для отладки сетевого ядра. Это позволяет выполнять отладку напрямую в виртуальной среде, предоставляя разработчикам удобный и эффективный процесс отладки. Дополнительную информацию о настройке сетевой отладки ядра можно найти в документации Microsoft.

Установка Windows Server 2025 в VMware vSphere

Перед развертыванием виртуальных машин с Windows Server 2025 в VMware vSphere рекомендуется ознакомиться с Руководством по совместимости Broadcom, чтобы убедиться в совместимости вашего оборудования и продуктов VMware. Это руководство содержит важную информацию о поддерживаемых серверах, устройствах хранения, сетевых адаптерах и других компонентах.

Для получения подробных инструкций по установке обратитесь к документации VMware: "Руководство по установке Windows Server 2025".

Ссылки и известные проблемы

Для устранения неисправностей и оптимизации развертывания виртуальных машин Windows Server 2025 на VMware vSphere ознакомьтесь с приведёнными ниже статьями базы знаний (KB). Эти статьи охватывают вопросы совместимости VMware Tools, а также решения известных проблем.

• VMware Tools compatibility with guest operating systems
• Windows Server 2025 Guest OS option is not Available During VMware vSphere ESXi Virtual Machine Creation
• Upgrading guest OS in VMware vSphere ESXi VM from Windows Server 2012 R2, Windows Server 2016, Windows Server 2019, Windows Server 2022 to Windows Server 2025
• Windows Server 2025 with a virtual NVME boot disk may fail to boot when other disks are on the same NVME controller
• Windows Server 2025 does not recognize virtual NVDIMM devices

В то время, как организации по всему миру стремятся преобразовать свою инфраструктуру, чтобы соответствовать требованиям цифровой эпохи, гиперконвергентное хранилище стало ключевым инструментом для модернизации ИТ. Решение VMware vSAN находится на переднем плане этой революции, предлагая гибкое, масштабируемое и экономически эффективное решение для управления критически важными рабочими нагрузками.

Однако, когда ИТ-служба принимает решение о внедрении новой технологии, такой как гиперконвергентное хранилище, первый шаг может казаться сложным. Есть очевидные моменты для начала, такие как обновление инфраструктуры или новое развертывание ИТ в периферийной локации. Что касается рабочих нагрузок, то кривая внедрения — какие нагрузки выбрать для старта и как продвигаться дальше — может представлять собой некоторую загадку.

VMware недавно заказала исследование Key Workloads and Use Cases for Virtualized Storage у компании Enterprise Strategy Group, чтобы изучить роль гиперконвергентного хранилища, его преимущества и ключевые случаи применения, где оно оказывает значительное влияние. Рекомендации основаны на опросах сотен пользователей гиперконвергентных хранилищ, а также на тысячах реальных внедрений.

Почему хранилище является проблемой

В стремительно меняющемся цифровом мире управление хранилищем становится сложной задачей. Объемы данных растут экспоненциально из-за таких факторов, как искусственный интеллект, интернет вещей (IoT) и облачные приложения. Сложность и фрагментация хранилищ также увеличиваются, поскольку данные распределены между локальными, облачными и периферийными локациями. Традиционные архитектуры хранилищ на основе трехуровневых систем становятся дорогостоящими, трудными для масштабирования и требуют специальных навыков. Это создает острую необходимость в новом подходе, который упрощает хранение данных, одновременно удовлетворяя растущие потребности современных приложений.

Роль гиперконвергентного хранилища

VMware vSAN устраняет ограничения традиционного хранилища с помощью гиперконвергентного подхода, который объединяет ресурсы хранилища нескольких серверов в единую общую базу данных. Это упрощает управление, улучшает производительность и обеспечивает постепенное масштабирование. В отличие от традиционного хранилища, которое является жестким и дорогим, гиперконвергентное хранилище предлагает гибкую модель, позволяющую организациям масштабироваться вверх или вниз по мере необходимости и работать на серверах промышленного стандарта, снижая капитальные затраты. Гиперконвергентное хранилище позволяет организациям использовать единую программно-определяемую инфраструктуру и единый операционный подход для основного датацентра, периферийной инфраструктуры и публичного облака, что значительно упрощает управление в крупных масштабах. VMware имеет обширный список совместимого оборудования, сертифицированного для работы vSAN как в периферийных системах, так и в основных датацентрах.

Кроме того, vSAN ускоряет рутинные операции с хранилищем, такие как предоставление хранилища за минуты, а не за часы или дни, что делает его идеальным решением для быстро меняющихся условий. Тесная интеграция с облачной инфраструктурой VMware позволяет без проблем управлять как виртуальными машинами, так и контейнерами, что делает его универсальным решением для частных и гибридных облачных сред.

Ключевые рабочие нагрузки для гиперконвергентного хранилища

VMware vSAN подходит для различных сценариев использования, демонстрируя в них свою гибкость и масштабируемость:

1. Виртуальная инфраструктура рабочих столов (VDI): с увеличением числа удаленных сотрудников виртуальные рабочие столы стали критически важными. Однако VDI требует высокой производительности, линейного масштабирования и технологий для сокращения объема данных, чтобы оптимизировать затраты на хранение. vSAN решает эту задачу, предлагая масштабируемое решение. Его архитектура поддерживает высокую производительность и различные технологии сокращения данных для минимизации требований к объему хранения.

2. Бизнес-критичные приложения: для требовательных приложений баз данных, таких как Oracle, SQL Server и SAP HANA, vSAN обеспечивает высокую производительность и масштабируемость. Архитектура vSAN Express Storage Architecture предоставляет высокую производительность и устойчивость, даже с использованием кодирования ошибок RAID 5/6 для эффективности. vSAN также позволяет независимо масштабировать вычислительные ресурсы и ресурсы хранения, что полезно для рабочих нагрузок OTLP, которые часто растут быстрее по объему хранения, чем по вычислительным требованиям.

3. «Мейнстримные» рабочие нагрузки: веб-серверы, аварийное восстановление и защита данных. Это зрелые и широко используемые приложения, для которых требуется простое в управлении и недорогое хранилище. vSAN упрощает работу с этим хранилищем для разных рабочих нагрузок за счет управления на основе политик и снижает затраты, используя серверы промышленного стандарта для достижения необходимой производительности. Он также упрощает аварийное восстановление, позволяя реплицировать данные между сайтами без дорогостоящего специального оборудования.

4. Рабочие нагрузки на периферии (edge workloads): гиперконвергентные решения для хранилищ обеспечивают масштабируемость, гибкость и повышенную производительность на периферии с меньшими затратами, в компактном формате и, что особенно важно, в упрощенном форм-факторе серверов. Ключевые возможности vSAN включают:

• возможность экономного масштабирования
• поддержку нативного файлового и блочного хранения для уменьшения физического объема
• высокую производительность благодаря поддержке NVMe-based TLC NAND flash для приложений с высокой чувствительностью к задержкам
• централизованное управление всеми удаленными сайтами из одного инструмента

5. Облачные (cloud-native) рабочие нагрузки: гиперконвергентные решения для хранилищ также являются идеальным подходом, поскольку они поддерживают облачные хранилища и автоматизируют выделение хранилища для контейнерных рабочих нагрузок, что позволяет разработчикам получать доступ к необходимому хранилищу по мере необходимости, одновременно позволяя ИТ-администраторам управлять хранилищем как для контейнеров, так и для виртуальных машин на одной платформе.

Заключение

VMware vSAN — это не просто решение для хранения, это краеугольный камень ИТ-модернизации. Благодаря использованию виртуализации vSAN позволяет организациям создать гибкую, масштабируемую и эффективную инфраструктуру хранения, способную справиться с текущими и будущими нагрузками. Независимо от того, хотите ли вы оптимизировать рабочие столы VDI, улучшить производительность баз данных или модернизировать стратегию аварийного восстановления, VMware vSAN предоставляет комплексное решение для удовлетворения потребностей пользователей.

VMware vSphere давно зарекомендовала себя как одна из ведущих платформ для виртуализации, обеспечивая мощные инструменты для управления виртуальными машинами (VM) и инфраструктурой центров обработки данных (ЦОД). В версии VMware vSphere 8 Update 3 была введена новая важная функция — Live Patch. Это нововведение позволяет администраторам вносить критические исправления и обновления безопасности в ядро гипервизора ESXi без необходимости перезагрузки системы или отключения виртуальных машин. В данной статье мы рассмотрим, что такое Live Patching, его преимущества, технические аспекты работы и потенциальные ограничения.

Выход платформы VMware vSphere 8 переопределил подход к управлению жизненным циклом и обслуживанием инфраструктуры vSphere. Решение vSphere Lifecycle Manager упрощает управление образами кластеров, обеспечивает полный цикл управления драйверами и прошивками, а также ускоряет полное восстановление кластера. Управление сертификатами происходит без сбоев, а обновления vCenter можно выполнять с гораздо меньшими простоями по сравнению с прошлыми релизами платформы.

vSphere 8 Update 3 продолжает эту тенденцию снижения и устранения простоев с введением функции vSphere Live Patch.

vSphere Live Patch позволяет обновлять кластеры vSphere и накатывать патчи без миграции рабочих нагрузок с целевых хостов и без необходимости перевода хостов в полный режим обслуживания. Патч применяется в реальном времени, пока рабочие нагрузки продолжают выполняться.

Требования данной техники:

• vSphere Live Patch является опциональной функцией, которую необходимо активировать перед выполнением задач восстановления.
• vCenter должен быть версии 8.0 Update 3 или выше.
• Хосты ESXi должны быть версии 8.0 Update 3 или выше.
• Настройка Enforce Live Patch должна быть включена в глобальных настройках восстановления vSphere Lifecycle Manager или в настройках восстановления кластера.
• DRS должен быть включен на кластере vSphere и работать в полностью автоматическом режиме.
• Для виртуальных машин с включенной vGPU необходимо активировать Passthrough VM DRS Automation.
• Текущая сборка кластера vSphere должна быть пригодна для применения live-патчинга (подробности ниже).

Как работает Live Patching

Кликните на картинку, чтобы открыть анимацию:

Распишем этот процесс по шагам:

• Хост ESXi переходит в режим частичного обслуживания (partial maintenance mode). Частичный режим обслуживания — это автоматическое состояние, в которое переходит каждый хост. В этом особом состоянии существующие виртуальные машины продолжают работать, но создание новых ВМ на хосте или миграция ВМ на этот хост или с него запрещены.
• Новая версия компонентов целевого патча монтируется параллельно с текущей версией.
• Файлы и процессы обновляются за счет смонтированной версии патча.
• Виртуальные машины проходят быструю паузу и запуск (fast-suspend-resume) для использования обновленной версии компонентов.

Не все патчи одинаковы

Механизм vSphere Live Patch изначально доступен только для определенного типа патчей. Патчи для компонента выполнения виртуальных машин ESXi (virtual machine execution component) являются первыми целями для vSphere Live Patch.

Патчи, которые могут изменить другие области ESXi, например патчи VMkernel, изначально не поддерживаются для vSphere Live Patch и пока требуют следования существующему процессу патчинга, который подразумевает перевод хостов в режим обслуживания и эвакуацию ВМ.

Обновления vSphere Live Patches могут быть установлены только на поддерживаемые совместимые версии ESXi. Каждый Live Patch будет указывать, с какой предыдущей сборкой он совместим. vSphere Lifecycle Manager укажет подходящие версии при определении образа кластера. Также вы можете увидеть подходящую версию в репозитории образов vSphere Lifecycle Manager:

Например, patch 8.0 U3a 23658840 может быть применен только к совместимой версии 8.0 U3 23653650. Системы, которые не работают на совместимой версии, все равно могут быть обновлены, но для этого будет использован существующий процесс "холодных" патчей, требующий перевода хостов в режим обслуживания и эвакуации ВМ.

Соответствие образа кластера будет указывать на возможность использования Live Patch.

Быстрое приостановление и возобновление (fast-suspend-resume)

Как упоминалось ранее, патчи для компонента выполнения виртуальных машин в ESXi являются первой целью для vSphere Live Patch. Это означает, что хотя виртуальные машины не нужно эвакуировать с хоста, им нужно выполнить так называемое быстрое приостановление и возобновление (FSR) для использования обновленной среды выполнения виртуальных машин.

FSR виртуальной машины — это ненарушающее работу действие, которое уже используется в операциях с виртуальными машинами при добавлении или удалении виртуальных аппаратных устройств (Hot Add) в работающие виртуальные машины.

Некоторые виртуальные машины несовместимы с FSR. Виртуальные машины, настроенные с включенной функцией Fault Tolerance, машины, использующие Direct Path I/O, и vSphere Pods не могут использовать FSR и нуждаются в участии администратора. Это может быть выполнено либо путем миграции виртуальной машины, либо путем перезагрузки виртуальной машины.

Сканирование на соответствие в vSphere Lifecycle Manager укажет виртуальные машины, несовместимые с FSR, и причину несовместимости:

После успешного восстановления кластера любые хосты, на которых работают виртуальные машины, не поддерживающие FSR, будут продолжать сообщать о несоответствии требованиям. Виртуальные машины необходимо вручную переместить с помощью vMotion или перезагрузить. Только тогда кластер будет полностью соответствовать требованиям (compliant).

Отметим, что vSphere Live Patch несовместим с системами, работающими с устройствами TPM или DPU, использующими vSphere Distributed Services Engine.

Вильям Лам написал интересную статью о том, как можно редактировать настройки SMBIOS для вложенного/виртуального (Nested) VMware ESXi в части hardware manufacturer и vendor.

Nested ESXi продолжает оставаться полезным ресурсом, который часто используется администраторами: от прототипирования решений, воспроизведения проблем клиентов до автоматизированных развертываний лабораторий, поддерживающих как VMware Cloud Foundation (VCF), так и VMware vSphere Foundation (VVF).

Хотя с помощью Nested ESXi можно сделать почти все, но имитировать или симулировать конкретные аппаратные свойства, такие как производитель или поставщик (hardware manufacturer и vendor), не совсем возможно или, по крайней мере, очень сложно. Коллега Вильяма Люк Хакаба нашел хитрый трюк, играя с настройками загрузочных ROM виртуальной машины по умолчанию, которые поставляются с ESXi и VMware Desktop Hypervisors (платформы Workstation/Fusion).

Виртуальная машина vSphere может загружаться, используя либо BIOS, либо EFI прошивку, поэтому в зависимости от желаемого типа прошивки вам нужно будет изменить либо файл BIOS.440.ROM, либо EFI64.ROM. Эти файлы ROM можно найти в следующих каталогах для соответствующих гипервизоров VMware:

• ESXi: /usr/lib/vmware/roms
• VMware Fusion: /Applications/VMware Fusion.app/Contents/Library/roms
• VMware Workstation: C:\Program Files (x86)\VMware\VMware Workstation\x64

Примечание: не редактируйте файлы ROM по умолчанию, которые поставляются с гипервизором VMware, сделайте их копию и используйте измененную версию, которую могут использовать виртуальные машины в VMware vSphere, Fusion или Workstation. Кроме того, хотя эта статья посвящена виртуальной машине Nested ESXi, это также должно работать и на других гостевых операционных системах для отображения информации SMBIOS.

Редактирование BIOS

Шаг 1 - Скачайте и установите Phoenix BIOS Editor. Установщик Phoenix BIOS Editor имеет проблемы при запуске на системе Windows Server 2019, и единственным способом завершить установку - это изменить совместимость приложения на Windows 8, что позволит успешно завершить установку.

Шаг 2 - Скачайте и откройте файл BIOS.440.ROM с помощью Phoenix BIOS Editor, затем перейдите на панель DMI Strings для изменения нужных полей.

Когда вы закончите вносить все изменения, перейдите в меню "Файл" и нажмите "Собрать BIOS" (Build BIOS), чтобы создать новый файл ROM. В данном примере это файл BIOS.440.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi. Второй вариант позволит вам повторно использовать один и тот же кастомный файл ROM в нескольких виртуальных машинах, поэтому, с точки зрения тестирования, возможно, вам захочется создать несколько файлов ROM в зависимости от ваших нужд и просто перенастроить виртуальную машину для использования нужного файла ROM.

Шаг 4 - Чтобы кастомный файл ROM мог быть использован нашей виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку (Advanced Setting) виртуальной машины, которая указывает путь к нашему кастомному файлу ROM:

bios440.filename = "BIOS.440.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить нашу виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS, как показано на скриншоте ниже.

Редактирование EFI

Шаг 1 - Скачайте и установите HEX-редактор, который может редактировать файл EFI ROM. Например, ImHex - довольно удобный с точки зрения редактирования, но поиск определенных строк с помощью этого инструмента является нетривиальной задачей.

Шаг 2 - Скачайте и откройте файл EFI64.ROM с помощью редактора ImHex и найдите строку "VMware7,1". Как только вы найдете расположение этой строки, вам нужно аккуратно отредактировать значения hex, чтобы получить желаемые ASCII строки.

Кроме того, вы можете использовать UEFITool (версия 28 позволяет модифицировать ROM), который имеет гораздо более удобный и функциональный поиск, а также позволяет извлекать часть файла ROM для редактирования с помощью HEX-редактора. В этой утилите можно использовать поиск (CTRL+F), и как только он находит нужный раздел, двойным щелчком по результату переходите к точному месту в файле ROM. Чтобы извлечь раздел для редактирования, щелкните правой кнопкой мыши и выберите "Extract as is" и сохраните файл на рабочий стол.

Затем вы можете открыть конкретный раздел с помощью ImHex, чтобы внести свои изменения.

После того как вы сохранили свои изменения, не теряйте указатель в UEFITool. Теперь мы просто заменим раздел нашим измененным файлом, щелкнув правой кнопкой мыши и выбрав "Replace as is", указав измененный раздел. Вы можете подтвердить, что изменения были успешными, просто найдя строку, которую вы заменили. Затем перейдите в меню "Файл" и выберите "Сохранить образ файла" (Save image file), чтобы создать новый файл ROM. В данном случае - это файл EFI64.CUSTOM.ROM.

Шаг 3 - Скопируйте новый файл ROM в хранилище вашего физического хоста ESXi. Вы можете сохранить его в общей папке, чтобы использовать с несколькими виртуальными машинами Nested ESXi, ИЛИ вы можете сохранить его непосредственно в папке отдельной виртуальной машины Nested ESXi.

Шаг 4 - Чтобы наш кастомный файл ROM мог быть использован виртуальной машиной Nested ESXi, нам нужно добавить следующую дополнительную настройку ВМ в файл vmx, которая указывает путь к нашему кастомному файлу ROM:

efi64.filename = "EFI64.CUSTOM.ROM"

Шаг 5 - Наконец, мы можем включить виртуальную машину Nested ESXi, и теперь мы должны увидеть кастомную информацию SMBIOS.

Как видно на скриншоте, Вильяму удалось изменить только модель оборудования, но не значение вендора.

Примечание: хотя автору и удалось найти строку "VMware, Inc." для вендора, изменение значения не оказало никакого эффекта, как показано на скриншоте выше, что, вероятно, указывает на то, что эта информация может храниться в другом месте или содержаться в каком-то встроенном файле.

Оказывается у сетевого адаптера виртуальной машины vmnic есть свойство, определяющее, будет ли он автоматически присоединяться к виртуальной машине при ее запуске. Свойство это называется StartConnected, оно может быть не установлено по каким-то причинам, что может привести к проблемам.

Как написал Farnky, проверить это свойство у всех виртуальных машин в окружении vCenter можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List

Если вы увидите в результатах значение NoStartConnected, значит этот адаптер vmnic не будет подключен при запуске ВМ:

Исправить эту ситуацию можно следующей командой:

#Get-VM "your target VM" | Get-NetworkAdapter | Set-NetworkAdapter -StartConnected $true -confirm:$false | select Parent, ConnectionState | Format-List

Те из вас, кто работает на компьютерах Apple Mac, часто используют виртуальные машины Windows, которые запускаются в виртуальных средах VMware Fusion и Parallels Desktop.

Однако Eric Sloof недавно обратил внимание на интересный продукт - платформу виртуализации UTM.

UTM предназначен для создания и запуска виртуальных машин на устройствах Apple. Это комплексный системный эмулятор и хост виртуальных машин, специально разработанный для iOS и macOS. Созданный на мощной платформе QEMU, UTM позволяет пользователям быстро запускать различные операционные системы, такие как Windows и Linux, на устройствах Mac, iPhone и iPad.

UTM является настоящим открытием для пользователей Apple Silicon (процессоры M1/M2). Он использует фреймворк виртуализации Hypervisor от Apple, позволяя операционным системам ARM64 работать на скоростях, почти идентичных скорости нативной работы.

Для владельцев Mac на Intel доступна возможность виртуализации операционных систем x86/x64. Но на этом возможности UTM не заканчиваются - он также предлагает менее производительную эмуляцию для запуска x86/x64 на Apple Silicon и ARM64 на Intel. Эта универсальность расширяется за счет поддержки ряда других эмулируемых процессоров, включая ARM32, MIPS, PPC и RISC-V, делая ваш Mac по-настоящему универсальной платформой.

UTM не только про современные ОС - он также способен вдохнуть жизнь и в классические операционные системы. Будь то старая система PowerPC, SPARC или x86_64, UTM позволяет запускать их на разных платформах в виде виртуальных машин. Любопытные пользователи могут посмотреть галерею, где представлены различные системы, которые может эмулировать UTM.

Вот, например, эмуляция MacOS 9.2.1:

Пользователи Mac на Apple Silicon могут вывести виртуализацию на новый уровень с помощью UTM. Он позволяет запускать несколько экземпляров macOS, что особенно полезно для разработчиков и пользователей, ориентированных на безопасность. Однако эта функция доступна исключительно на Mac на базе ARM с установленной macOS Monterey или более новой версией.

UTM выделяется среди другого ПО для виртуализации благодаря своему дизайну, который создан исключительно для macOS и платформ Apple. Он гармонично сочетается со стилем Big Sur, предлагая пользовательский опыт, который действительно напоминает Mac, включая все ожидаемые функции конфиденциальности и безопасности.

В своей основе UTM использует QEMU - хорошо известного, бесплатного и открытого программного обеспечения для эмуляции. Сам QEMU достаточно сложен в использовании, что часто отпугивает пользователей большим количеством параметров командной строки. UTM устраняет этот барьер, предлагая надежные функции QEMU без сложности, делая его доступным для более широкого круга пользователей.

Скачать UTM для ваших Apple-устройств можно по этой ссылке.

Дункан Эппинг опубликовал интересный пост о том, как предотвратить исполнение виртуальных машин vCLS на VMware vSphere HA Failover Host. Напомним, что vSphere Clustering Service (vCLS) - это служба, которая позволяет организовать мониторинг доступности хостов кластера vSphere, без необходимости зависеть от служб vCenter. Она реализуется тремя агентскими виртуальными машинами в кластере, где 3 или более хостов, и двумя, если в кластере два хоста ESXi. Три машины нужны, чтобы обеспечивать кворум (2 против 1) в случае принятия решения о разделении кластера.

Для тех, кто не знает, сервер vSphere HA Failover Host — это хост, который используется, когда происходит сбой и vSphere HA должен перезапустить виртуальные машины. В некоторых случаях клиенты (обычно партнеры в облачных решениях) хотят предотвратить использование этих хостов для любых рабочих нагрузок, поскольку это может повлиять на стоимость использования платформы.

К сожалению, в пользовательском интерфейсе вы не можете указать, что машины vCLS не могут работать на определенных хостах, вы можете ограничить работу ВМ vCLS рядом с другими виртуальными машинами, но не хостами. Однако есть возможность указать, на каких хранилищах данных могут находиться виртуальные машины, и это может быть потенциальным способом ограничения хостов, на которых могут работать эти ВМ. Как?

Если вы создадите хранилище данных, которое недоступно назначенному Failover-хосту vSphere HA, то машины vCLS не смогут работать на этом хосте, так как хост не сможет получить доступ к датастору. Это обходной путь для решения проблемы, вы можете узнать больше о механизме размещения хранилищ данных для vCLS в этом документе. Обратите внимание, что если остальная часть кластера выйдет из строя и останется только Failover-хост, виртуальные машины vCLS не будут включены. Это означает, что механизм балансировки нагрузки VMware DRS также не будет функционировать, пока эти ВМ недоступны.

Мы помним, что некоторые из вас просили рассказать о российских альтернативах платформам виртуализации от ведущих мировых вендоров. Оказывается, еще в 2022 году компании TAdviser и Softline подготовили подробное описание и сравнение российских платформ виртуализации по разным критериям, которое является хорошей отправной точкой для тех, кто больше не имеет возможности использовать продукты VMware.

Вот основные ссылки на информацию о российских производителях ПО для серверной виртуализации:

• ITglobal.com (продукт vStack, мы много писали о нем тут)
• ГК АСТРА (продукты "Брест", Termidesk, ISPsystem VMmanager)
• "Аэродиск" (продукт "Аэродиск Аист")
• ИЦ «Баррикады» (продукт "Горизонт-ВС")
• BaseAlt (продукт "Альт-Сервер Виртуализация")
• "Киберпротект" (продукт "Кибер Инфраструктура")
• НИИ "Масштаб" (продукт Veil)
• "Облачная платформа" (продукт BASIS)
• OrionSoft (продукт Zvirt)
• РедСофт (продукт "РЕД Виртуализация")
• ROSA (продукт ROSA VIRTUALIZATION)
• "Росплатформа" (продукт «Р-Виртуализация»)
• "Тионикс холдлинг" (продукт Accentos)
• ИК "Хост" (продукт HOSTVM)
• SharxDC (продукт SharxBase)

Ну а вот результаты сравнения этих платформ:

Обратите внимание, что данное исследование и сравнение сделано в декабре 2022 года, с тех пор многое могло измениться (в зависимости от активности разработчиков).

Полную версию этого отчета на 47 страницах можно скачать по этой ссылке (нужно заполнить форму внизу страницы):

На сайте VMware Developer появился полезный сценарий PowerCLI, который позволяет администратору изменить текущий контроллер SCSI на новый тип для виртуальной машины на платформе VMware vSphere.

Некоторые особенности работы этого сценария:

• Не проверяет, настроена ли виртуальная машина для 64-битной гостевой ОС (адаптер BusLogic не поддерживается)
• Ппроверяет, работают ли VMware Tools и выключает виртуальную машину с помощью функции выключения гостевой ОС
• Возвращает виртуальную машину в предыдущее рабочее состояние
• Проверяет, было ли уже установлено новое значение контроллера SCSI

Функция Modify-ScsiController вызывается в самом конце скрипта. Вот различные примеры того, как функция может быть использована:

Скачать данный сценарий можно по этой ссылке.

Администраторы виртуальной инфраструктуры VMware vSphere время от времени сталкиваются с проблемой завершения зависших виртуальных машин. Если в клиенте vSphere Client сделать этого не удаются, приходится заходить в сервисную консоль ESXi или в командную строку PowerCLI/PowerShell и проводить там операции по завершению процесса этой ВМ. Сегодня мы расскажем о 5 способах, которыми это можно сделать.

1. С использованием PowerCLI

Stop-VM - это командлет, используемый для завершения работы виртуальной машины. На самом деле он используется для выключения ВМ, но добавление параметра kill приведет к завершению соответствующих процессов ВМ на ESXi, фактически уничтожая ее. Делается это так:

Stop-VM -kill <отображаемое имя ВМ> -Confirm:$false

2. С использованием esxcli

Esxcli - это интерфейс командной строки (CLI), который предоставляет доступ к ряду пространств имен, таких как vm, vsan, network и software, позволяя выполнять задачи, изменять настройки и так далее. Таким образом, если вам нужно завершить работу неотвечающей виртуальной машины с использованием esxcli, можно действовать следующим образом:

• Получить список виртуальных машин, размещенных на ESXi:

esxcli vm process list

Красным выделен идентификатор World ID виртуальной машины.

• Скопируйте значение World ID и выполните команду:

esxcli vm process kill --type=soft -w=796791

Команда не выдает никакой обратной связи, кроме случаев, когда она не сможет найти виртуальную машину или вы укажете неверный параметр.

Параметр type принимает три значения:

• Soft – позволяет процессу VMX завершиться корректно, аналогично команде kill -SIGTERM
• Hard – немедленно завершает процесс VMX, аналогично команде kill -9 или kill -SIGKILL
• Force – останавливает процесс VMX, когда не работают варианты Soft или Hard

3. С использованием утилиты vim-cmd

Vim-cmd - это еще одна утилита командной строки, очень похожая на esxcli, но с несколько иным синтаксисом. Также она может использоваться для управления ВМ и другими ресурсами. Соответственно, вот как используется vim-cmd для завершения работы ВМ:

1. Выведите все ВМ на текущем подключенном хосте ESXi и запишите vmid (первый столбец) неотвечающей ВМ:

vim-cmd vmsvc/getallvms

2. Получите состояние питания ВМ, используя ее vmid. Этот шаг необязателен, так как вы уже знаете, что с ВМ что-то не так:

vim-cmd vmsvc/power.getstate 36

3. Сначала попробуйте вариант power.shutdown:

vim-cmd vmsvc/power.shutdown 36

4. Если по какой-то причине ВМ не удается выключить, попробуйте использовать вместо этого power.off:

vim-cmd vmsvc/power.off 36

Следующий скриншот демонстрирует пример использования указанных выше команд для завершения работы ВМ.

4. С использованием esxtop

Esxtop - это отличная утилита, которая предоставляет информацию о том, как ESXi использует системные ресурсы. Она может использоваться для устранения неполадок, сбора статистики производительности и многого другого.

Вот как это делается:

Нажмите Shift+v, чтобы изменить представление на виртуальные машины:

Нажмите <f>, чтобы отобразить список полей, затем нажмите <c>. Это добавит столбец с идентификатором Leader World ID (LWID) в представление. Нажмите любую клавишу, чтобы вернуться в главное меню.

• Найдите зависшую виртуальную машину в столбце Name и запишите ее LWID.
• Нажмите k и введите значение LWID в строке запроса World to kill (WID). Нажмите Enter:

Чтобы быть полностью уверенным, подождите 30 секунд перед тем, как проверить, что виртуальная машина больше не отображается в списке. Если она все еще там, попробуйте снова. В случае неудачи, скорее всего, вам придется перезагрузить хост ESXi.

5. С помощью традиционной команды kill

Это самый грубый метод завершения работы виртуальной машины. Но он документирован на сайте VMware, хотя и немного по-другому. Виртуальная машина представляет собой серию процессов, выполняемых на ESXi. Используя команду ps ниже, можно вывести процессы, связанные, например, с виртуальной машиной под названием Web Server.

ps | grep "Web Server"

Если вы внимательно посмотрите, вы увидите, что значение во втором столбце одинаково для всех процессов. Это значение идентификатора VMX Cartel, которое, хотя и отличается от значения World ID, все же может быть использовано для завершения работы виртуальной машины следующим образом:

kill 797300

Если процессы продолжают работать, попробуйте kill -9 <идентификатор процесса>:

kill -9 797300

В прошлых статьях мы рассказывали об архитектуре платформы виртуализации vStack и ее технических возможностях, а также о ее требованиях к оборудованию. Сегодня мы поговорим о процедуре установки этого решения. Установка ПО vStack проста и состоит из нескольких последовательных шагов...

В последние годы появилось большое число российских платформ виртуализации. Одна из них — vStack, решение с оригинальным стеком технологий. Сегодня мы расскажем об этой платформе, которая надежно зарекомендовала себя среди множества корпоративных заказчиков. В первую очередь, мы будем говорить об архитектуре платформы и о том, как она устроена с технической точки зрения...

На сайте проекта VMware Labs появилась очередная новая утилита - Horizon Instant Clone Associated VMs. Это инструмент, разработанный для помощи администраторам в управлении внутренними виртуальными машинами, связанными с их пулами Horizon. С помощью него вы легко можете определить неиспользуемые виртуальные машины и удалить их всего в несколько кликов, а также сэкономить ценное дисковое пространство и навести порядок в виртуальной инфраструктуре.

Инструмент Horizon Instant Clone Associated VMs содержит несколько полезных функций для операций с виртуальными машинами в инфраструктуре Horizon:

• Генерация отчетов - возможность создания отчетов, которые показывают связь внутренних ВМ Instant Clone с пулами Horizon. Отчеты доступны в форматах HTML и Excel (.xlsx).
• Удаление неиспользуемых ВМ - утилита позволяет вам определить и быстро удалить неиспользуемые внутренние ВМ. Эта функция может помочь вам освободить дисковое пространство и навести порядок в вашей виртуальной среде.

• Определение "сиротских" (orphaned) внутренних ВМ - есть возможность определить "сиротские" внутренние ВМ, которые были удалены, но все еще отображаются в окружении vCenter Server. Выполнив пару действий, вы можете удалить эти ВМ и повысить эффективность вашей виртуальной среды.
• Удаление внутренних ВМ, указанных в текстовом файле - утилита позволяет вам удалить внутренние ВМ, перечисленные в текстовом файле. Эта штука особенно полезна, когда вам нужно быстро и эффективно удалить большое количество ВМ, имена которых известны.

Для работы продукта вам понадобится Windows 10 x64 / Windows Server 2016 или более поздние, PowerShell версии 5.1 и позднее, а также модуль VMware PowerCLI.

Скачать Horizon Instant Clone Associated VMs можно по этой ссылке.

Вильям Лам опубликовал интересную статью о шаблонах виртуальных машин (VM Templates), разъясняющую некоторые возможности по их использованию в библиотеках контента.

Часто неправильно понимаемой возможностью библиотеки контента vSphere является управление и распространение шаблонов виртуальных машин (VM Templates), которая была представлена в vSphere 6.7 Update 2.

Для библиотек контента в vSphere 5.0 контент распространялся с использованием репликации на основе запроса, при которой на клиентском vCenter Server настраивалась подписка на контент сервера-издателя vCenter Server, а затем контент скачивался на сервер подписчика, как показано на рисунке ниже.

Эта первоначальная архитектура библиотеки контента vSphere упрощала любому vCenter Server, независимо от его домена Single Sign-On, создание подписки и загрузку контента (файлы ISO, OVF/OVA и другие) из vSphere Content Library сервера-издателя.

Создание подписки на библиотеку контента vSphere полностью управлялось подписывающимся vCenter Server, если он знал URL подписки и учетные данные для подключения к серверу-издателю vCenter Server. Хотя это упрощало подписку на контент из библиотеки контента vSphere для всех, это также означало, что для больших организаций с множеством серверов vCenter Server требовалась дополнительная задача по настройке каждого подписывающегося vCenter Server.

После того как контент был синхронизирован с подписчиком vCenter Server, не было простого способа контролировать, какие пользователи могут развертывать определенные OVF/OVA из библиотеки контента vSphere, что может быть проблемой для организаций, которые требуют тонкого контроля доступа к развертыванию рабочих нагрузок. Как гарантировать, что конкретные пользователи/группы развертывают подходящие или последние образы?

Когда возможность управления шаблонами VMTX была добавлена в библиотеку контента vSphere, это не только ввело новую функцию Check-In/Check-Out для шаблонов виртуальных машин, но и добавило новый метод управления распространением образов виртуальных машин через несколько серверов vCenter с использованием новой репликации на основе push, которая исходит от сервера-издателя vCenter Server.

Вместо того чтобы идти на каждый подписывающийся vCenter Server для создания подписки на библиотеку контента vSphere, теперь вы можете управлять всеми подписками непосредственно с сервера-издателя vCenter Server. Этот дополнительный метод репликации библиотеки контента vSphere требует, чтобы все серверы vCenter Server, которые хотят подписаться на образы VMTX, участвовали либо в Enhanced Linked Mode (ELM), либо в Hybrid Linked Mode (HLM), где онпремизный vCenter Server публикует контент на vCenter Server VMware Cloud на AWS (в обратную сторону пока не поддерживается).

Поскольку подписка на библиотеку контента vSphere управляется и настраивается на сервере-издателе vCenter Server, должно существовать доверие между сервером-издателем и сервером-подписчиком vCenter Server, чтобы иметь возможность создавать подписку с сервера-издателя vCenter Server, и именно поэтому требуется один из вариантов Linked-режимов, чтобы иметь возможность использовать новую возможность синхронизации VTMX.

Имея такое сопряжение, чтобы управлять и создавать подписки на ваши серверы-подписчики vCenter Server, включая образы VMTX, вам нужно выбрать желаемую библиотеку контента vSphere на вашем сервере-издателе vCenter Server и в новой вкладке "Subscriptions", как показано на скриншоте ниже.

Хотя при использовании новой функции VMTX в библиотеке контента vSphere есть некоторые узкие места, есть и большие преимущества перед управлением традиционными образами OVF/OVA. Некоторые администраторы знают, что нет способа контролировать, каким пользователям разрешено развертывать из конкретных образов OVF/OVA из библиотеки контента vSphere.

С VMTX у вас на самом деле есть возможность назначать детализированные права пользователям и группам, которые определяют, кто может видеть и развертывать конкретные образы VMTX, что является результатом того, что образ VMTX является частью инвентаря vSphere, что означает, что вы получаете преимущества от механизма прав vCenter Server.

Ниже приведен пример, где есть два образа VMTX: Photon-3.0 и Photon-4.0 в одной библиотеке контента vSphere, и права назначаются таким образом, что они соответственно отображаются на пользователя lob1-user и lob2-user, которым затем разрешено развертывать на основе прав, которые усатновлены на образы VMTX.

Кроме того, мы можем также ограничить, какой контент должен видеть конкретный подписывающийся vCenter Server, особенно если у ваших развертываний vCenter Server есть различные требования по контенту. С моделью на основе pull, все пользователи в подписывающихся серверах vCenter Server смогут видеть только все OVF/OVA из опубликованной библиотеки контента vSphere, и это может быть или не быть желаемым результатом в зависимости от потребностей вашей организации.

Альтернативный подход к ограничению доступа к OVF/OVA заключается в создании нескольких библиотек контента vSphere с сервера-издателя vCenter Server, но это может привести к дублированию контента, который должен быть в нескольких библиотеках, что потребляет дополнительное место хранения и добавляет дополнительную сложность.

С новым же подходом вы можете управлять одной библиотекой контента vSphere со всеми желаемыми VMTX, а затем использовать права vSphere для предоставления дополнительного контроля доступа в каждом подписывающемся vCenter Server. Наконец, чтобы гарантировать, что каждый подписывающийся vCenter Server не загружает ненужные образы VMTX, которые не могут быть использованы, вы всегда должны рассматривать возможность включения настройки "Загрузка контента библиотеки по мере необходимости" и предварительно загружать только тот контент, который, как вы знаете, может или будет использоваться подписывающимся vCenter Server.

Многие администраторы сталкиваются с необходимостью обновления пакета VMware Tools в большом количестве виртуальных машин, работающих на серверах ESXi платформы VMware vSphere.

Общие сведения об обновлении VMware Tools

На данный момент можно использовать один из трех способов массового VMware Tools в большой инфраструктуре:

• Применение средства VMware vSphere Lifecycle Manager (ранее его функционал был частью VMware Update Manager)
• Написание сценариев для фреймворка VMware vSphere PowerCLI
• Использование сторонних утилит для обновления тулзов

В отличие от версий аппаратной обеспечения (VM Hardware), компания VMware рекомендует всегда использовать последнюю версию пакета VMware Tools, для которого есть матрицы совместимости с различными версиями хостов ESXi. Посмотреть их можно по этой ссылке.

Например, мы видим, что VMware Tools 2016 года все еще можно использовать в ВМ на ESXi 7.0 U3. Также виртуальная машина на сервере VMware ESXi 5.5 может иметь текущую версию VMware Tools (сейчас это 12.1.5).

Напомним, что VMware Tools - это не только часть дистрибутива vSphere, но и отдельный продукт, который можно скачать с портала Customer Connect.

Есть несколько вариантов по загрузке этого пакета:

• Бандл для общего репозитория Locker (например, VMware-Tools-windows-12.1.5-20735119.zip) - он используется для создания локального или общего репозитория с нужной версией VMware Tools.
• Установщик в гостевой ОС, который можно запустить в ней как исполняемый файл (VMware-tools-12.1.5-20735119-x86_64.exe.zip).
• Пакеты для GuestStore (gueststore-vmtools-12.1.5-20735119-20735876.zip) - это новая возможность, которая появилась в vSphere 7.0 U2. GuestStore сделан не для обновления VMware Tools, но может использоваться для этой цели (это тема для отдельной статьи).
• Офлайн VIB-пакет с тулзами (VMware-Tools-12.1.5-core-offline-depot-ESXi-all-20735119.zip) - он используется как Baseline для обновления VMware Tools на хостах.

Исторически пакет VMware Tools, в основном, выпускался для Windows и Linux. Есть также версии этого пакета и для FreeBSD, Solaris и MacOS. Здесь есть следующие нюансы:

• Тулзы версии 10.3.5 for Linux были заморожены в разработке, вместо них теперь есть пакет open-vm-tools.
• Начиная с версии VMware Tools 10.2.0, инсталляция на базе Perl-скриптов для FreeBSD больше не поддерживается. В этом случае также надо использовать open-vm-tools.
• Последняя версия тулзов для гостевых ОС Solaris - это 10.3.10.

Как мы увидим дальше, очень важно знать, какая версия VMware Tools размещена локально на хосте ESXi после его установки. Эта версия может быть использована для проверки актуальных пакетов в виртуальных машинах. Для быстрой проверки текущей версии пакета на хосте можно использовать следующую команду:

esxcli software component get | grep VMware-VM-Tools -B 1 -A 14

Если вы хотите использовать для этого PowerCLI, то можно выполнить следующий сценарий:

	
$Result = @()

foreach ($ViHost in (Get-VMhost)) {

    $esxcli = $ViHost | Get-esxcli -V2

    $ToolsVersion = ($esxcli.software.component.get.Invoke() | Where-Object {$_.name -eq "VMware-VM-Tools"}).Version

    $Result += [PSCustomObject] @{

        HostName = $ViHost.Name;

        ToolsVersion = $ToolsVersion}

}

$Result

Способы обновления VMware Tools

Итак, рассмотрим обновление VMware Tools одним из двух способов:

• Обновление VMware Tools как отдельного пакета ПО

В этом случае для нужно версии тулзов можно использовать любое средство, например Microsoft System Center, которое предназначено для массового развертывания программ. Также вы можете использовать любые скрипты и другие средства в режиме тихой установки (silent install).

• Обновление VMware Tools посредством функционала vSphere

При развертывании и апгрейде хостов ESXi на них помещаются соответствующие версии VMware Tools (чтобы узнать список версий, загляните сюда). По умолчанию пакеты помещаются в папку /productLocker на хосте ESXi - это symbolic link, то есть просто указатель на настроенную папку. Чтобы узнать, какая версия VMware Tools является текущей, сервер vCenter сравнивает установленную версию тулзов в ВМ с версией, которая хранится в разделе /productLocker. Если актуальная версия в гостевой ОС меньше хранящейся на хосте, то в vSphere Client вы увидите соответствующее предупреждение:

Далее вам нужно выполнить процедуру, состоящую из двух основных шагов:

• Настраиваем хост ESXi для использования определенной версии VMware Tools
• Автоматизируем процесс обновления тулзов в гостевых ОС виртуальных машин

Шаг 1 - Настройка хоста ESXi для использования определенной версии VMware Tools

Надо сказать, что не рекомендуется вручную обновлять содержимое папки /productLocker, так как это не поддерживаемый официально процесс, и при апгрейде хоста вы можете получить более старую версию пакета. Также вы можете использовать конкретную версию VMware Tools для всех ВМ (например, ту, что содержит исправление конкретного бага).

Это рекомендуемый способ обновления пакета VMware Tools, здесь может быть использован один из двух пакетов обновления хостов в кластере:

• Baseline based
• Single image

Если вы обновляете кластер, используя базовые уровни (baselines), вы можете создать кастомный образ, который включает желаемые версии VMware Tools, либо вы можете развернуть тулзы с использованием кастомного бейзлайна.

Давайте посмотрим на обновление с использованием метода Baseline:

• Просто скачиваем VMware Tools Offline VIB bundle

• Загружаем бандл на vSphere Lifecycle Manager (либо VIB-пакет может быть загружен этим продуктом автоматически)
• Создаем новый базовый уровень, содержащий только пакет VMware Tools VIB
• Привязываем бейзлайн к тому уровню иерархии, для которого будут выполняться апдейты, а также запускаем проверку комплаенса на хостах
• Выполняем функцию Remediate для накатывания VMware Tools для ВМ на хостах ESXi

После успешного апдейта, локальный репозиторий VMware Tools также будет обновлен.

Несмотря на то, что хост не нужно перезагружать после обновления, он все равно должен быть помещен в режим обслуживания (maintenance mode). В противном случае, процесс обновления может выглядеть успешным, но в реальности изменений на хосте не произойдет.

Теперь посмотрим на процесс обновления VMware Tools методом Single Image:

Это более современный метод обновления тулзов на хостах в кластере. Вам нужно выбрать нужную версию VMware Tools как дополнительного компонента при определении образа.

В этом случае можно изменить только версию VMware Tools, а остальное можно оставить как есть.

Создаем общий репозиторий для нужной версии VMware Tools

Этот подход создает центральный репозиторий VMware Tools для нескольких хостов. В этом случае они не будут использовать локальный репозиторий, а на общем хранилище будет использоваться общая папка, которая станет новым репозиторием. Преимуществом данного подхода является обслуживание только одного экземпляра репозитория. Процесс создания этого репозитория описан в KB 2129825.

Как это выглядит по шагам:

1. Создаем на общем томе VMFS папку и устанавливаем для нее разрешения:

cd /vmfs/volumes/datastore
mkdir vmtools-repository-name
chmod 700 vmtools-repository-name

2. Если вы хотите использовать уже использованный репозиторий, то папку надо очистить:

rm -rf /vmfs/volumes/datastore/vmtools-repository-name/*

3. Добавляем файлы, загруженные из Customer Connect и распакованные, в эту папку - у вас получится две подпапки, содержащие нужные файлы:

На скриншоте показан пример для VMware Tools под Windows. Если вы хотите использовать старые тулзы для Linux, то их нужно добавить в папку vmtools. Также посмотрите вот эту нашу статью о VMware Tools.

4. Устанавливаем правильные разрешения:

chmod -R 700 /vmfs/volumes/datastore/vmtools-repository-name/*

5. Если вы делаете процедуру впервые, то нужно настроить хосты ESXi для использования данной папки репозитория вместо используемой локальной папки по умолчанию. Для этого вам нужно добавить расширенную настройку UserVars.ProductLockerLocation (по умолчанию она указывает на /locker/packages/vmtoolsRepo/). Напомним, что /productLocker - это символьная ссылка, поэтому нужно использовать полный путь.

Так как мы обсуждаем массовое обновление тулзов, то имеет смысл показать здесь применение данного способа с использованием PowerCLI:

• Для вывода текущей директории Locker выполняем следующий командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Select-Object Entity, Value

• Для изменения директории выполняем такой командлет:

Get-VMHost | Get-AdvancedSetting -Name "UserVars.ProductLockerLocation" | Set-AdvancedSetting -Confirm:$false -Value "/vmfs/volumes/datastore/vmtools-repository-name/"

Будьте аккуратны при вызове второй команды, так как она меняет параметр на всех хостах, которые вы указали.

6. После этого вам нужно будет перезагрузить хост для обновления символьной ссылки /productLocker.

Шаг 2 - Автоматизация процесса обновления тулзов в гостевых ОС виртуальных машин

Теперь мы готовы автоматизировать апдейты VMware Tools в гостевой ОС. Так как мы говорим о массовом обновлении пакетов, то мы не будем обсуждать вариант с логином в гостевую ОС, монтирования ISO-образа и запуском exe-файла.

Сначала посмотрим, какие версии сейчас установлены в виртуальных машинах, с помощью PowerCLI. Запускаем следующую команду:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsVersion}}

Это не самая удобная нотация, но она соответствует той, что мы видим на странице VM Summary на сервере vCenter. Для получения параметров этой команды используйте маппинг-файл версий.

4 способа автоматизации обновления VMware Tools в гостевой ОС:

1. Обновляем VMware Tools немедленно или ставим запланированную задачу через vCenter

Через интерфейс не всегда удобно работать с массовым обновлением, но в данном случае это можно сделать с помощью отфильтрованного списка ВМ и установки настроек по срабатыванию действий с объектами.

vSphere Lifecycle Manager имеет довольно мощный функционал в этом плане. Процесс обновления можно запланировать на базе состояния питания ВМ. Также можно задать опции предварительного создания снапшота ВМ.

Выбираем нужный кластер, идем на вкладку Updates и выбираем VMware Tools. Фильтруем нужные нам ВМ или выбираем все, далее кликаем Upgrade to match host. В следующих окнах у вас будет множество опций для создания запланированной задачи:

Вы можете не только настроить создания снапшота перед апдейтом, но и задать число часов, по истечении которых снапшот будет удален. Также в состав снапшота может входить и состояние оперативной памяти.

Также помните, что массовое удаление снапшотов в одно время может создать очень большую нагрузку на хранилище. Поэтому лучше снапшоты использовать только для самых критичных ВМ, которые должны сразу оказаться доступными в случае каких-либо проблем.

Дефолтные настройки для этих параметров вы можете установить здесь: Menu -> Lifecycle Manager -> Settings -> VMs:

2. Мгновенное обновление VMware Tools через vSphere PowerCLI

Для обновления тулзов на выбранных хостах (или всех) используется командлет Update-Tools. Он инициирует процесс обновления пакета изнутри гостевой ОС. По умолчанию Update-Tools ждет завершения обновления, после чего инициируется процесс перезагрузки ВМ. Это поведение можно изменить, используя параметры NoReboot и RunAsync.

Следующая команда начинает процесс обновления в виртуальной машине Win2019-01 в рамках задачи:

Get-VM Win2019-01 | Update-Tools –RunAsync

Чтобы посмотреть статус выполняемых задач, используйте команду Get-Task:

Так как это команда PowerShell - ее также можно добавить в запланированные задачи.

3. Обновление VMware Tools при следующей загрузке ВМ в интерфейсе vSphere Client

В рамках окна обслуживания виртуальные машины обычно можно перезагружать. Его, как раз, можно использовать и для обновления VMware Tools. Для этого надо настроить ВМ для проверки версии тулзов при загрузке. Если установленная версия меньше необходимой (по ссылке в /productLocker), то начинается процесс апдейта.

Для изменения политики обновлений, выберите нужный кластер и перейдите на вкладку Updates, где выберите VMware Tools. Там можно фильтровать список ВМ:

После того, как вы выберете машины, можно задать политику автообновления для них:

4. Обновление тулзов при следующей загрузке с использованием vSphere PowerCLI

Сначала посмотрим, текущую конфигурацию ВМ через PowerCLI:

Get-VM | Select-Object Name, @{N="ToolsVersion"; E={$_.ExtensionData.Config.Tools.ToolsUpgradePolicy}}

Здесь могут быть следующие политики - manual и UpgradeAtPowerCycle. Нам нужно использовать вторую. Итак, сначала определяем переменные:

$vmConfigSpec = New-Object VMware.Vim.VirtualMachineConfigSpec
$vmConfigSpec.Tools = New-Object VMware.Vim.ToolsConfigInfo
$vmConfigSpec.Tools.ToolsUpgradePolicy = "UpgradeAtPowerCycle"

Далее применяем эти политики к виртуальным машинам:

$VMs = Get-VM -Name "Win*"
$VMs.ExtensionData.ReconfigVM_Task($vmConfigSpec)

Уделите особое внимание тому факту, какие ВМ вы поместите в переменную $VMs. При таком подходе для обновления VMware Tools вы не сможете запланировать создание предварительных снапшотов ВМ.

Недавно компания Microsoft выпустила обновление KB5022842 для Windows от 14 февраля, которое, к сожалению, приводит к неработоспособности виртуальных машин на платформе VMware vSphere 7, если для них включен режим безопасной загрузки (Secure Boot). Проблема описана вот тут (Microsoft также подтвердила со своей стороны), там же есть и PowerCLI-скрипт для выявления таких машин:

$secureBoot2022VMs = foreach($datacenter in (Get-Datacenter)) {
  $datacenter | Get-VM |
    Where-Object {$_.Guest.OsFullName -Match 'Microsoft Windows Server 2022' -And $_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled} |
      Select-Object @{N="Datacenter";E={$datacenter.Name}},
        Name,
        @{N="Running OS";E={$_.Guest.OsFullName}},
        @{N="Secure Boot";E={$_.ExtensionData.Config.BootOptions.EfiSecureBootEnabled}},
        PowerState
}
$secureBoot2022VMs | Export-Csv -NoTypeInformation -Path ./secureBoot2022VMs.csv

При попытке запустить такую ВМ она не включится, а в логе vmware.log в папке с ВМ вы увидите такие записи:

2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Signature: 0 in db, 0 in dbx, 1 unrecognized, 0 unsupported alg.

2023-02-15T05:34:31.379Z In(05) vcpu-0 - Hash: 0 in db, 0 in dbx.

2023-02-15T05:34:31.379Z In(05) vcpu-0 - SECUREBOOT: Image DENIED.

Ситуация была исправлена со стороны VMware в патче обновлений vSphere 7 Update 3k (KB 90947), который предлагается установить всем пользователям, затронутых этой ситуацией.

Отметим, что с виртуальными машинами на vSphere 8 никаких неприятностей не произошло.

Скачать VMware vSphere 7 Update 3k можно по этой ссылке. Release Notes находятся тут.

Спасибо Сергею за новость.

На днях обновилась известная многим администраторам виртуальной инфраструктуры утилита RVTools до версии 4.4.1. Напомним, что она предназначена для помощи пользователю VMware vSphere в различных аспектах при выполнении рутинных операций в виртуальной среде серверов ESXi и виртуальных машин. В прошлый раз об RVTools 4.3.1 мы писали вот тут.

Давайте посмотрим, что нового появилось в RVTools 4.4.1:

• Теперь утилита разрабатывается на Visual Studio 2022.
• RVTools использует обновленный VMware vSphere Management SDK 8.0.
• Log4net обновлен до версии 2.0.15.
• Компонент RVToolsPasswordEncryption теперь использует mac-адрес вместо фиксированной строки для шифрования пароля.
• Новые колонки на странице vInfo: емкость диска в MiB, Folder ID, роль Fault tolerance, операции Reboot/Poweroff, опция EFI Secure boot, SMBIOS UUID.
• Новая колонка на странице vCPU - Numa Hotadd Exposed. Это булевое значение, показывающее работает ли NUMA-топология при включенном CPU hotadd.
• Новые колонки на странице vDisk: Disk UUID и Disk sharing mode.
• На всех страницах, относящихся к ВМ, колонка с тэгами поставлена перед колонкой Datacenter. Также изменен текст тултипа VM UUID на "VirtualCenter-specific 128-bit UUID of a virtual machine".
• Новые колонки на странице vSource: version, patch level и VI SDK Server.
• На странице vHealth путь /storage/archive исключен из проверки free disk capacity, так как этот раздел может быть заполнен изначально в нормальной конфигурации (подробнее тут).
• Исправлена ошибка с некорректным отображением колонки Primary IP Address на странице vInfo.
• Решена проблема на странице vNetwork, когда нельзя было понять, является ли IP-адрес типом ipv4 или ipv6.

Скачать новую версию RVTools 4.4.1 можно по этой ссылке. Описание отображаемых параметров находится тут.