В начале года мы рассказывали о ситуации вокруг продукта VMware vCenter Converter, предназначенного для миграции физических и виртуальных серверов в онпремизную и облачную среду VMware vSphere. На тот момент Converter был убран из списка доступных загрузок из соображений обеспечения совместимости, стабильности и безопасности, так как продукт многие годы не развивался - последний релиз VMware vCenter Conterter был от мая 2018 года (там была и его версия VMware Converter Standalone), хотя, по-сути, не обновлялся он несколько лет до этого. Поддержка этого продукта закончилась в декабре 2019, а последний раз до этого о нем мы упоминали вот тут.
Выглядел он тогда так:
И вот на днях компания VMware объявила о выпуске новой версии продукта VMware vCenter Converter Standalone 6.3.0, который поддерживает миграцию на платформу VMware vSphere 7, включая ее пакеты обновлений. К сожалению, поддержки vSphere 8 мы пока не получили (хотя технически перевести туда виртуальную машину с помощью Converter не очень-то сложно).
Давайте посмотрим на новые возможности Converter 6.3.0:
1. Обновился список поддерживаемых физических платформ для установки Converter
Теперь для целей P2V (Physical-to-Virtual) и V2V (Virtual-to-Virtual) миграции вы можете установить конвертер на следующие десктопные и серверные системы:
Windows Server 2012 (64-bit)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
2. Обновился список поддерживаемых гостевых ОС для конвертации
Теперь с помощью vCenter Converter вы можете перенести в виртуальную среду vSphere виртуальные и физические машины под управлением следующих операционных систем:
Windows Server 2012 (64-bit)
Windows 8.1 (32-bit and 64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
CentOS 6.x (32-bit and 64-bit)
Red Hat Enterprise Linux 6.x (32-bit and 64-bit)
Red Hat Enterprise Linux 7.x (64-bit)
Ubuntu 14.04 LTS (32-bit and 64-bit)
Ubuntu 16.04 LTS (32-bit and 64-bit)
Внимание! При переносе следующих файловых систем машин Linux их файловые системы будут сохранены:
ext2
ext3
ext4
reiserfs
vfat
xfs
Все остальные ФС будут сконвертированы при миграции в ext3 или ext4 на целевой виртуальной машине.
3. Обновился список поддерживаемых платформ для V2V-миграции
Теперь можно переносить в среду vSphere виртуальные машины под управлением гипервизора Hyper-V на следующих платформах Microsoft:
Windows Server 2012 (64-bit)
Windows Server 2012 R2 (64-bit)
Windows 10 (32-bit and 64-bit)
Windows Server 2016 (64-bit)
Windows Server 2019 (64-bit)
Windows 11 (64-bit)
Windows Server 2022 (64-bit)
4. Поддержка целевых платформ VMware
Теперь виртуальные и физические машины можно перенести на следующие платформы VMware:
VMware vSphere 6.5 (Update 3)
VMware vSphere 6.7 (Update 3)
VMware vSphere 7.0
VMware vSphere 7.0 (Update 1)
VMware vSphere 7.0 (Update 2)
VMware vSphere 7.0 (Update 3)
VMware Workstation 16.x
VMware Fusion 12.x
5. Программа Customer Experience Improvement Program
Теперь продукт vCenter Converter участвует в программе CEIP, что подразумевает сбор информации о пользовательских окружениях в целях улучшения их опыта. В рамках CEIP собирается следующая информация о виртуальной среде:
Configuration Data – как и что у вас настроено в плане продуктов и сервисов VMware.
Feature Usage Data - как именно вы используете возможности продуктов и сервисов.
Performance Data - производительность различных объектов виртуальной инфраструктуры в виде метрик и численных значений (отклик интерфейса, детали об API-вызовах и прочее).
Если в рамках вашего плана поддержки вы используете Enhanced Support для CEIP, то на серверы VMware для анализа отправляются еще и продуктовые логи (Product Logs). Документация по CIEP доступна здесь.
Несколько важных моментов при использовании vCenter Converter:
Converter Standalone 6.3.0 не поддерживает версии Virtual Hardware выше 11. У целевых машин возможности будут ограничены именно этой версией виртуального железа. Дальнейший апгрейд вам надо делать самостоятельно.
Пока поддерживается только размер секторов 512B (512e и 512n). Нативные 4K-диски (4Kn) не поддерживаются.
Converter Standalone 6.3 поддерживает только те ОС RHEL 6.x и CentOS 6.x, которые используют SSH-ключи с аутентификацией RSA SHA1. Новые алгоритмы, такие как RSA SHA2 или ECDSA, не поддерживаются.
Скачать VMware vCenter Converter Standalone 6.3.0 можно по этой ссылке. Release Notes доступны тут.
Довольно давно мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Также некоторое время назад мы писали о VMware Paravirtual RDMA (PVRDMA) - технологии, поддержка которой появилась еще в VMware vSphere 6.5. С помощью нее для сетевых адаптеров PCIe с поддержкой RDMA можно обмениваться данными памяти для виртуальных машин напрямую через RDMA API, что важно для нагрузок High Performance Computing (HPC) на платформе vSphere.
Работает PVRDMA только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Альтернативой этому режиму использования сетевых карт является технология VMDirectPath I/O (passthrough), которая напрямую пробрасывает устройство в виртуальную машину. Это, конечно, самый оптимальный путь с точки зрения производительности, однако он не позволяет использовать многие полезные технологии VMware, такие как HA, DRS и vMotion.
Недавно компания VMware выпустила интересный документ "Paravirtual RDMA for High Performance Computing", где рассматриваются аспекты развертывания и производительности PVRDMA, а также производится тестирование этой технологии в сравнении с VMDirectPath I/O и TCP/IP:
Читать весь документ, наверное, не стоит - можно довериться методике тестирования VMware и ее подходу к оценке производительности. Тестовый стенд выглядел так:
Состав оборудования и особенности тестирования:
8 хостов ESXi 7.0 на платформе PowerEdge C6420 с Intel Xeon Gold 6148 CPU на борту (20 ядер / 40 потоков), 200GB RAM NVIDIA Mellanox ConnectX-5 Ex 100GbE NIC на канале RDMA
Карты NVIDIA Mellanox ConnectX-5 Ex NIC, соединенные через коммутатор 100GbE NVIDIA Mellanox
CentOS 7.6, 20 vCPUs, 100GB RAM, ВМ на датасторе vSAN, одна ВМ на хост ESXi
OpenMPI версии 4.1.0, использующая using openib BTL для транспорта RDMA
OpenFOAM версии 8, исполняющая тест cavityFine из руководства OpenFOAM. Этот тест исполняет симуляцию течения жидкости с заданными параметрами.
Тут можно просто взглянуть на следующие картинки, чтобы понять, что при использовании PVRDMA вы теряете не так уж и много в сравнении с VMDirectPath I/O.
Результаты теста по времени исполнения в секундах (для 2,4 и 8 хостов, соответственно):
Визуализация результатов при изменении числа узлов:
В среднем, потери производительности на PVRDMA составляют до 20%, зато вы получаете множество преимуществ, которые дает полная виртуализация без жесткой привязки к оборудованию - консолидация, HA и vMotion:
В сравнении с TCP дела тоже обстоят хорошо, результат лучше на 30-80%, в зависимости от числа узлов:
Скачать документ VMware Paravirtual RDMA for High Performance Computing можно по этой ссылке.
Релиз платформы VMware vSphere 6.5 в свое время (а это была осень 2016 года) оказался довольно удачным, поэтому до сих пор довольно большое количество пользователей используют его в производственной среде.
В июне прошлого года VMware объявила о продлении поддержки vSphere 6.7 в связи с пандемией, но кто ж знал, что все настолько поменяется, поэтому о продлении срока поддержки версии 6.5 сообщили только сейчас.
Теперь период general support period для vSphere 6.5 продлен на 11 месяцев до 15 октября 2022 года, что совпадает с аналогичным для vSphere 6.7. До этого момента достижение точки прекращения предоставления полной технической поддержки (EoGS, End of General Support) было намечено на 15 ноября 2021 года. Но окончание технического сопровождения (EoTG, End of Technical Guidance) не изменилось - оно наступит 15 ноября 2023 года.
У VMware нет планов продлевать период Extended Support для vSphere 6.5, поэтому тем, кому это важно, следует смигрировать хотя бы на vSphere 6.7, где расширенная поддержка будет действовать подольше.
Расширение поддержки для vSphere 6.5 будет с некоторыми ограничениями:
Нужно будет использовать vCenter 6.7 для хостов ESXi 6.5, потому что там есть обновленный vSphere Client вместо старого Web Client.
Для хостов на базе vCenter Server Appliance нужно будет обновиться на vCenter Server to 6.7 Update 3 (см. тут подробнее).
vCenter Server for Windows нужно проапгрейдить до vCenter Server to 6.7 Patch 05 или более поздней версии (см. тут).
Если вы не сможете обновить vCenter, то будет допустимо использовать vCenter 6.5, но как-то поддерживать работоспособность Flash-клиента (см. тут).
Аналогично продляются сроки оказания технической поддержки для VMware vSAN 6.5 и 6.6 до тех же дат и с теми же условиями, что и для vSphere: теперь окончание поддержки наступит 15 октября 2022 года, но EoTG также не изменится:
Ограничения расширения поддержки для vSAN остаются теми же, что и для VMware vSphere.
Многие администраторы виртуальной инфраструктуры VMware vSphere при планировании апгрейда не выясняют важных моментов, касающихся совместимости продуктов и так называемых upgrade paths, то есть поддерживаемых производителем рабочих процессов обновления платформы. В этой статье мы расскажем о том, что нужно выяснить перед апгрейдом...
Большинство администраторов, которым требуется управление виртуальной инфраструктурой VMware vSphere с помощью сценариев используют интерфейс VMware PowerCLI, который является оберткой движка PowerShell. Это требует наличие отдельного хоста, с которого идет исполнение сценариев, а также часто требуются такие сервисы, как vRealize Orchestrator и vRealize Automation.
Поэтому, начиная с VMware vSphere 6.7, появился новый Open Source интерфейс для управления виртуальной средой - Script Runtime Service (SRS). Он представляет собой Kubernetes-приложение для управления инстансами PowerCLI и вызова командлетов через REST API.
Интерфейс SRS позволит интегрировать управление исполнением сценариев PowerCLI в vSphere Client для виртуальных машин и приложений.
SRS создает отдельное пространство имен в кластере Kubernetes, которое позволяет PowerCLI работать как Kubernetes pod. Этот легковесный PowerCLI pod реализуется как образ контейнера, который имеет все модули PowerCLI и требует только необходимые управляющие компоненты, трансформирующие ввод и вывод для сценариев, а также управляющие исполнением запрошенного сценария.
Первоначальная инсталляция SRS запускает задачу Kubernetes, которая регистрирует SRS в сервисах провайдера идентификации vSphere SSO. Единожды аутентифицированные клиенты SRS API автоматически включаются в список доверенных на серверах vCenter.
Надо отметить, что сейчас SRS находится еще в ранней стадии разработки и не работает с vSphere with Tanzu (поэтому не развертывайте его со службами Supervisor Cluster).
Попробовать работу с движком SRS можно двумя путями:
1. Устанавливаете SRS в кластере Kubernetes на любую из машин (инструкции здесь)
2. Устанавливаете SRS на специальным образом подготовленную виртуальную машину на базе Photon OS (инструкции тут).
Начать экспериментировать с SRS API можно, перейдя по ссылке:
https://{SRS-IP}/swagger/index.html
SRS использует механизм vCenter Server SSO для идентификации и аутентификации. У любого пользователя с доступом через SSO есть возможность настроить PowerCLI-соединения к серверам vCenter Servers. Как начать это делать описано вот тут.
SRS работает с vSphere 6.7 и более поздними версиями. Сообщить о проблемах вы можете вот тут, а также присодинившись к VMware Code и каналу в Slack.
Некоторое время назад мы писали о технологии Remote Direct Memory Access (RDMA) которая позволяет не использовать CPU сервера для удаленного доступа приложения к памяти другого хоста. RDMA позволяет приложению обратиться (в режиме чтение-запись) к данным памяти другого приложения на таргете, минуя CPU и операционную систему за счет использования аппаратных возможностей, которые предоставляют сетевые карты с поддержкой этой технологии - называются они Host Channel Adaptor (HCA).
Устройства HCA могут коммуницировать с памятью приложений на сервере напрямую. Грубо говоря, если в обычном режиме (TCP) коммуникация по сети происходит так:
То при наличии на обоих хостах HCA, обмен данными будет происходить вот так:
Очевидно, что такая схема не только снижает нагрузку на CPU систем, но и существенно уменьшает задержки (latency) ввиду обхода некоторых компонентов, для прохождения которых данными требуется время.
Поддержка RDMA появилась еще в VMware vSphere 6.5, когда для сетевых адаптеров PCIe с поддержкой этой технологии появилась возможность обмениваться данными памяти для виртуальных машин напрямую через RDMA API. Эта возможность получила название Paravirtual RDMA (PVRDMA).
Работает она только в окружениях, где есть хосты ESXi с сетевыми картами с соответствующей поддержкой, а также где виртуальные машины подключены к распределенному коммутатору vSphere Distributed Switch (VDS). Метод коммуникации между виртуальными машинами в таком случае выбирается по следующему сценарию:
Если две машины общаются между собой на одном ESXi, то используется техника memory copy для PVRDMA, что не требует наличия HCA-карточки на хосте, но сама коммуникация между ВМ идет напрямую.
Если машины находятся на хостах с HCA-адаптерами, которые подключены как аплинки к VDS, то коммуникация идет через PVRDMA-канал, минуя обработку на CPU хостов, что существенно повышает быстродействие.
Если в коммуникации есть хоть одна ВМ на хосте, где поддержки RDMA на уровне HCA нет, то коммуникация идет через стандартный TCP-туннель.
Начиная с VMware vSphere 7 Update 1, для PVRDMA была добавлена поддержка оконечных устройств с поддержкой RDMA (Native Endpoints), в частности хранилищ. Это позволяет передать хранилищу основной поток управляющих команд и команд доступа к данным от виртуальных машин напрямую, минуя процессоры серверов и ядро операционной системы. К сожалению для таких коммуникаций пока не поддерживается vMotion, но работа в этом направлении идет.
Чтобы у вас работала технология PVRDMA для Native Endpoints:
ESXi должен поддерживать пространство имен PVRDMA. Это значит, что аппаратная платформа должна гарантировать, что физический сетевой ресурс для виртуальной машины может быть выделен с тем же публичным идентификатором, что и был для нее на другом хосте (например, она поменяла размещение за счет vMotion или холодной миграции). Для этого обработка идентификаторов происходит на сетевых карточках, чтобы не было конфликтов в сети.
Гостевая ОС должна поддерживать RDMA namespaces
на уровне ядра (Linux kernel 5.5 и более поздние).
Виртуальная машина должна иметь версию VM Hardware 18
или более позднюю.
За счет PVRDMA для Native Endpoints виртуальные машины могут быстрее налаживать коммуникацию с хранилищами и снижать задержки в сети, что положительно сказывается на производительности как отдельных приложений и виртуальных машин, так и на работе виртуального датацентра в целом.
Суть ее заключается в том, что при удалении снапшота ВМ, по завершении ее резервного копирования, она замирает примерно на 30 секунд, не принимая никакой ввод-вывод. Происходит это на некоторых NFS-хранилищах, в частности HPE SimpliVity. В итоге - приложения, чувствительные ко времени, работают плохо, ну и в целом такое поведение не очень приятно для производственных систем.
Проблема проявилась при использовании платформы VMware vSphere 6.7, текущей версии Veeam Backup and Replication и хранилища HPE SimpliVity, которое поддерживает презентацию томов только в режиме NFS v3.
При этом в такой же комбинации продуктов, но на блочных хранилищах удаление снапшота занимало 1-2 секунды.
После общения с поддержкой нашлись следующие workaround'ы, которые не подошли:
Использовать NFS v4 вместо v3 (доступно не на всех хранилищах)
Использовать другой транспорт (transport mode), например, Direct access или NBD (Network Block Device). Но Direct access доступен не всегда, а NBD - медленный режим.
Можно использовать режим hot-add с виртуальным модулем backup appliance, но тогда он должен быть на каждом хосте (см. KB 201095).
Можно отключить синхронизацию времени с хостом для ВМ с приложениями, которые страдают из-за замирания времени в гостевой ОС. Об этом можно почитать в KB 1189. Но это так себе решение.
На текущий момент получается, что это проблема именно VMware ESXi, см. статью KB 2010953. Также она описана и в базе знаний Veeam - KB 1681 (там же указаны и обходные пути). Таким образом, выходит, что в некоторых случаях ни одно из решений не подходит на 100%.
На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:
Давайте посмотрим, что нового появилось в vCenter и ESXi:
vCenter 6.7 Update 3j
Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
Обновления базовой операционной системы Photon OS.
В основном, этот релиз содержит исправления ошибок, среди которых есть и критические ошибки, приводившие к падению хоста ESXi. Полный список фиксов доступен в тут.
VMware Tools 11.1.5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.
Небольшое обновление ESXi 6.5 Update 3 PO5
В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут.
Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.
Напомним, что Intel Optane DC persistent memory (DCPMM) - эта память не такая быстрая как DRAM и имеет бОльшие задержки, но они все равно измеряются наносекундами. При этом данная память позволяет иметь ее большой объем на сервере, что существенно повышает плотность ВМ на одном хосте.
Модули DCPMM изготавливаются под разъем DDR4 и доступны планками по 128, 256 и 512 ГБ. В одной системе может быть до 6 ТБ памяти DCPMM. Платформа VMware vSphere 6.7 EP10 и более поздние версии поддерживают память Intel Optane persistent memory 100 series (она же Intel Optane PMem) со вторым поколением процессоров Intel Xeon Scalable в режимах App Direct и Memory.
В указанном документе рассматривается производительность данной памяти в новом режиме Balanced Profile для конфигурации BIOS, который впервые появился в процессорах Intel этой серии в целях повышения производительности. За счет данного режима производительность памяти увеличилась в 1.75 раза, как показано на картинке по результатам тестов:
Мы много писали о возможностях новой версии платформы VMware vSphere 7 (например, тут и тут), но нововведений там столько, что это не уместить и в десять статей. Сегодня мы поговорим об изменениях в структуре разделов
(Partition Layout), которые произошли в VMware ESXi 7.
Первое, что надо отметить, что до vSphere 7 разделы были фиксированного объема, а их нумерация была статической, что ограничивало возможности по управлению ими, например, в плане поддержки больших модулей, функций отладки и стороннего ПО.
Поэтому в vSphere 7 были увеличены размеры загрузочных областей, а системные разделы, которые стали расширяемыми, были консолидированы в один большой раздел.
В VMware vSphere 6.x структура разделов выглядела следующим образом:
Как мы видим, размеры разделов были фиксированы, кроме раздела Scratch и опционального VMFS datastore. Они зависят от типа загрузочного диска (boot media) и его емкости.
В VMware vSphere 7 произошла консолидация системных разделов в область ESX-OSData:
Теперь в ESXi 7 есть следующие 4 раздела:
System boot - хранит boot loader и модули EFI. Формат: FAT16.
Boot-banks (2 штуки)
- системное пространство для хранения загрузочных модулей ESXi. Формат: FAT16.
ESX-OSData - унифицированное хранилище дополнительных модулей, которые не необходимы для загрузки. К ним относятся средства конфигурации и сохранения состояния, а также системные виртуальные машины. Формат: VMFS-L. Для этой области нужно использовать долговременные хранилища на базе надежных устройств.
Как вы видите, ESX-OSData разделен на две части: ROM-data и RAM-data. Часто записываемые данные, например, логи, трассировка томов VMFS и vSAN EPD, глобальные трассировки, горячие базы данных - хранятся в RAM-data. В области ROM-data хранятся нечасто используемые данные, например, ISO-образы VMware Tools, конфигурации, а также дампы core dumps.
В зависимости от размера устройства, куда устанавливается ESXi, меняется и размер всех областей, кроме system boot:
Если размер устройства больше 128 ГБ, то ESXi 7 автоматически создает VMFS-тома.
Когда вы используете для запуска ESXi устройства USB или карточки SD, то раздел ESX-OSData создается на долговременном хранилище, таком как HDD или SSD. Когда HDD/SSD недоступны, то ESX-OSData будет создан на USB-устройстве, но он будет содержать только ROM-data, при этом RAM-data будет храниться на RAM-диске (и не сохранять состояние при перезагрузках).
Для подсистем ESXi, которым требуется доступ к содержимому разделов, используются символьные ссылки, например, /bootbank и /altbootbank. А по адресу /var/core лежат дампы core dumps:
В VMware vSphere Client можно посмотреть информацию о разделах на вкладке Partition Details:
Ту же самую информацию можно получить и через интерфейс командной строки ESXi (команда vdf):
Обратите внимание, что соответствующие разделы смонтированы в BOOTBANK1 и 2, а также OSDATA-xxx.
Кстати, вы видите, что OSDATA имеет тип файловой системы Virtual Flash File System (VFFS). Когда OSDATA размещается на устройствах SDD или NVMe, тома VMFS-L помечаются как VFSS.
ESXi поддерживает множество устройств USB/SD, локальных дисков HDD/SSD, устройств NVMe, а также загрузку с тома SAN LUN. Чтобы установить ESXi 7 вам нужно выполнить следующие требования:
Boot media размером минимум 8 ГБ для устройств USB или SD
32 ГБ для других типов устройств, таких как жесткие диски, SSD или NVMe
Boot device не может быть расшарен между хостами ESXi
Если вы используете для установки ESXi такие хранилища, как M.2 или другие не-USB девайсы, учитывайте, что такие устройства могут быстро износиться и выйти из строя, например, если вы используете хранилища VMFS на этих устройствах. Поэтому удалите тома VMFS с таких устройств, если они были созданы установщиком по умолчанию.
Еще в версии VMware vSphere 6.7 появилась интересная новая возможность платформы виртуализации - перезагрузка гипервизора без рестарта всего хоста ESXi. Очевидно, что главное преимущество такого подхода - уменьшенное время на загрузку серверов, некоторые из которых грузятся ну ооочень долго.
Ведь для некоторых обновлений и патчей необязательно аппаратно перезагружать хост и реинициализировать все его оборудование, что происходит при стандартной загрузке (процесс power-on self-test, POST). Достаточно лишь перезагрузить программную часть платформы.
Возможность быстрой перезагрузки ESXi Quick Boot может быть использована компонентами vSphere Update Manager или vSphere Lifecycle Manager (vLCM).
Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по этому поводу приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:
Для корректной работы Quick Boot есть и некоторые ограничения. Если вы используете vSphere 6.7, то Quick Boot не будет работать, если у вас включен TPM, есть устройства passthru, а также загружены драйверы vmklinux. Для версии vSphere 7.0 ограничением является только включенный TPM.
Для проверки хоста ESXi на совместимость с Quick Boot нужно выполнить следующую команду в консоли (она выведет полный список факторов, препятствующих использованию быстрой загрузки, таких как драйверы, оборудование и т.п.):
/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py
Включить быструю загрузку можно в настройках Update Manager или Lifecycle Manager через vSphere Client или Web Client (этот клиент доступен только для vSphere 6.7):
Более-менее заметные изменения появились только в vCenter 6.7 U3g:
Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
Обновления Photon OS, о которых можно почитать вот тут.
Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).
Недавно мы писали о новых возможностях платформы виртуализации VMware vSphere 7, а также функциональности нового механизма динамического распределения нагрузки VMware DRS 2.0. Среди новых возможностей DRS мы упоминали про функции Assignable Hardware, которые позволяют назначить профили устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU для первоначального размещения виртуальных машин в кластере.
Сегодня мы поговорим об этой технологии в целом. Ранее виртуальные машины, использовавшие технологии DirectPath I/O или vGPU, привязывались к физическому адресу устройства, который включал в себя адрес расположения устройства на конкретной шине PCIe конкретного хоста ESXi. Это делало невозможным использование такой ВМ на других серверах кластера, что, конечно же, делало невозможным и работу технологий HA и DRS, которые являются критически важными в современных датацентрах.
Теперь же технология Assignable Hardware вводит новый уровень абстракции, который включает в себя профиль с возможностями устройств, требующихся для виртуальной машины. Таких профилей два - для технологии Dynamic DirectPath I/O и для NVIDIA vGPU:
Таким образом, технология Assignable Hardware позволяет отделить виртуальную машину от конкретного устройства и дать ей возможность быть запущенной на другом хосте ESXi с таким же устройством (или даже другим, но поддерживающим определенный набор функций).
Теперь при настройке виртуальной машины у вас есть выбор одного из следующих вариантов для устройства PCIe:
DirectPath I/O (legacy-режим, без интеграции с HA и DRS)
Dynamic DirectPath I/O
NVIDIA vGPU
После того, как вы выберете нужный профиль оборудования, механизм DRS сможет разместить машину на хосте ESXi с поддержкой нужных функций для ВМ.
На скриншоте выше, во второй опции Select Hardware, также есть лейбл "GPGPU example" - это возможность задать определенным устройствам метки таким образом, чтобы при выборе размещения ВМ использовались только устройства хостов с данными метками (при этом модели устройств могут отличаться, например, NVIDIA T4 GPU и RTX6000 GPU). Либо можно выбрать вариант использования только идентичных устройств.
Назначить метку можно во время конфигурации PCIe-устройств. В гифке ниже показано, как это делается:
При использовании NVIDIA vGPU для виртуальной машины выделяется только часть устройства. Поддержка горячей миграции vMotion для машин, использующих vGPU, уже была анонсирована в VMware vSphere 6.7 Update 1. Теперь эта поддержка была расширена, в том числе для DRS, который теперь учитывает профили vGPU.
Ну и в видео ниже вы можете увидеть обзор технологии Assignable Hardware:
Таги: VMware, vSphere, Hardware, NVIDIA, vGPU, VMachines, DRS, vMotion, HA
На днях, как вы знаете, было много интересных новостей. И вот еще одна - компания VMware анонсировала большое обновление своей флагманской платформы виртуализации VMware vSphere 7. Напомним, что прошлая мажорная версия этого решения VMware vSphere 6.7 вышла весной 2018 года.
Сразу скажем, что это лишь анонс, а не объявление о доступности новой версии продукта для скачивания - как правило, GA версия vSphere появляется в течение месяца после анонса. Поэтому будем пока ожидать VMware vSphere 7 в апреле, а сегодня расскажем о новых возможностях этой платформы.
1. Улучшения сервисов VMware vCenter
Здесь можно отметить упрощение топологии vCenter Server SSO:
Возможность апгрейда vCenter Server для пользователей с внешним PSC на консолидированную топологию на базе одного сервера vCSA.
Embedded PSC теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается.
Профили vCenter Server Profiles:
Эта новая возможность для серверов vCenter работает точно так же, как Host Profiles работает для хостов. Теперь вы можете сравнивать и экспортировать настройки серверов vCenter в формате JSON для целей резервного копирования или применения этих настроек к другому серверу vCenter через REST API.
Функции vCenter Multi-Homing:
Теперь для управляющего трафика vCSA можно использовать до 4 адаптеров vNIC, среди которых один vNIC зарезервирован для механизма vCHA.
Улучшения Content Library
Теперь появилось новое представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для управления версиями шаблонов и возможностью откатиться к предыдущей версии.
Сначала делается Check-Out для открытия возможности внесения изменений, потом можно сделать Check-In для сохранения изменений в библиотеке.
Новая функция vCenter Server Update Planner:
Новая возможность доступна как часть vSphere Lifecycle Manager (vLCM) для серверов vCenter.
С помощью планировщика обновлений можно получать оповещения об обновлениях vCenter, планировать апгрейды, накатывать их, а также проводить анализ "что если" перед проведением обновления.
Возможность выполнения pre-upgrade проверок для выбранного сервера vCenter.
2 Улучшения механизма VMware DRS
Теперь DRS запускается каждую минуту, а не каждые 5 минут, как раньше.
Для генерации рекомендаций используется механизм VM DRS score (он же VM Hapiness).
Теперь это Workload centric механизм - это означает, что теперь в первую очередь учитываются потребности самой виртуальной машины и приложения в ней, а только потом использование ресурсов хоста.
Расчеты по памяти основываются на granted memory вместо стандартного отклонения по кластеру.
Появился механизм Scaleable Shares, который позволяет лучше выделать Shares в пуле ресурсов с точки зрения их балансировки.
3. Улучшения vMotion
Тут появились такие улучшения:
Улучшения миграций для Monster VM (с большими ресурсами и очень высокой нагрузкой), что позволяет увеличить шанс успешной миграции.
Использование только одного vCPU при отслеживании изменившихся страниц (page tracer) вместо всех vCPU, что меньше влияет на производительность во время миграции.
Уменьшение времени переключения контекста на другой сервер (теперь меньше одной секунды). Достигается за счет переключения в тот момент, когда compacted memory bitmap уже передана на целевой сервер, вместо ожидания передачи full bitmap.
4. Новые функции vSphere Lifecycle Manager (vLCM)
Здесь можно отметить 2 улучшения:
Функция Cluster Image Management, которая включает обновления firmware, драйверов и образов ESXi разных версий.
Первоначальная поддержка решений Dell OpenManage и HP OneView.
5. Возможности Application Acceleration (Tech Preview)
Эти функции пришли от приобретенной компании Bitfusion. Они позволяют оптимизировать использование GPU в пуле по сети, когда vGPU может быть частично расшарен между несколькими ВМ. Это может использоваться для рабочих нагрузок задач приложений AI/ML.
Все это позволяет организовать вычисления таким образом, что хосты ESXi с аппаратными модулями GPU выполняют виртуальные машины, а их ВМ-компаньоны на обычных серверах ESXi исполняют непосредственно приложения. При этом CUDA-инструкции от клиентских ВМ передаются серверным по сети. Подробнее можно почитать у нас тут.
6. Функции Assignable Hardware
Эта возможность позволяет использовать так называемый Dynamic DirectPath I/O для машин, которым требуется работа с устройствами PCIe passthrough и Nvidia GRID. Теперь с его помощью можно подобрать хосты с определенными требованиями к аппаратным компонентам, такими как vGPU и PCIe. Это позволяет, в свою очередь, использовать для таких ВМ технологии HA и DRS Initial Placement в кластере, где есть совместимые по оборудованию хосты ESXi.
7. Управление сертификатами
Здесь 2 основных новых возможности:
Новый мастер импорта сертификатов.
Certificate API для управления сертификатами с помощью сценариев.
8. Возможности Identity Federation
Функции ADFS теперь поддерживаются из коробки, также будет поддерживаться больше IDP, использующих механизмы OAUTH2 и OIDC.
9. Функции vSphere Trust Authority (vTA)
vTA использует отдельный кластер хостов ESXi, чтобы создать отдельный аппаратный узел доверия.
Этот кластер сможет зашифровывать вычислительный кластер и его ВМ вместе с vCenter и другими управляющими компонентами.
Можно использовать механизм аттестации, когда требуются ключи шифрования.
Теперь проще добиться соблюдения принципа наименьших привилегий, а также расширить пространство аудита.
10. Возможность vSGX / Secures Enclaves (Intel)
Расширения Intel Software Guard Extensions (SGX) позволяют переместить чувствительную логику и хранилище приложения в защищенную область, к которой не имеют доступа гостевые ОС и гипервизор ESXi.
Возможности SGX исключают использование vMotion, снапшотов, Fault Tolerance и других технологий. Поэтому SGX лучше использовать только тогда, когда по-другому нельзя.
11. Новое издание vSphere with Kubernetes (Project Pacific)
О Project Pacific мы подробно рассказывали вот тут. Он представляет собой набор средств для преобразования среды VMware vSphere в нативную платформу для кластеров Kubernetes. vCenter Server предоставляет возможности по управлению кластерами k8s (любые кластеры старше n-2 будут обновлены). Также в решение интегрирован Harbor, который может быть включен для каждого пространства имен.
Доступно это пока только для пользователей VMware Cloud Foundation (4.0), так как решение завязано на компонент VMware NSX-T.
12. Улучшения VMware Tools
Функции Guest Store теперь доступны в гостевой ОС (такие как обновление VMware Tools из гостевой ОС).
13. Обновленное железо (VM Hardware v17)
Тут основные улучшения таковы:
Virtual Watchdog Timer - теперь нет зависимости от физического железа для рестарта ВМ в случае, если гостевая ОС не отвечает.
Precision Time Protocol (PTP) - для приложений очень чувствительных ко времени (например, торговые платформы для трейдеров) можно использовать PTP вместо NTP и назначать его использование для виртуальных машин.
14. Улучшения vSphere Client
Здесь появились следующие улучшения:
Начала сохраняться история поиска.
В API Explorer теперь лучше видны все доступные API.
Для Code Capture появилась возможность выбора языка сценариев - PowerCLI, Javascript, Python или Go.
Конечно же, это далеко не все новые возможности VMware vSphere 7, представленные на днях. В ближайшее время мы расскажем еще много нового о них, а кроме того, посмотрим также и на анонсированные решения семейства VMware Tanzu, VMware Cloud Foundation 4 и vRealize 8.1.
Не так давно мы писали о политиках хранилищ SPBM на базе тэгов в кластере VMware vSAN. Это один из механизмов категоризации объектов, который может применяться не только к хранилищам, но и хостам, виртуальным машинам и другим объектам. Появился он еще в версии VMware vSphere 5.1.
На днях компания VMware выпустила интересный документ VMware vSphere 6.7 Tagging Best Practices, в котором описаны лучшие практики по использованию тэгов в виртуальной инфраструктуре.
В документе рассматривается использование API для тэгов, работа с которым происходит через интерфейсы Java или PowerShell.
Например, вот команда по выводу всех виртуальных машин, которым назначен определенный тэг:
// List tags associated with tagId from above
// Assumes tagAssociation object from above
List retDynamicIds = tagAssociation.listAttachedObjects(tagId);
А вот так можно вывести список всех тэгов для конкретной виртуальной машины:
$allCategoryMethodSVC = Get-CisService com.vmware.cis.tagging.category
$alltagMethodSVC = Get-CisService com.vmware.cis.tagging.tag
$allTagAssociationMethodSVC = Get-CisService com.vmware.cis.tagging.tag_association
# Use first VM from above list
$useThisVMID = $useTheseVMIDs[0]
$tagList = $allTagAssociationMethodSVC.list_attached_tags($useThisVMID)
Больше двух лет назад мы писали о средстве DRS Dump Insight, появившемся на сайте проекта VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS.
Также мы писали о специальном плагине на базе HTML5 к vSphere Client для данного сервиса. Он добавляет функции утилиты DRS Dump Insight в интерфейс vSphere Client, работающего с сервером vCenter Server Appliance (vCSA).
На днях вышло обновление DRS Dump Insight 1.1, в котором появились следующие новые возможности:
Пользователи теперь могут загружать несколько дампов, указав папку, в которой все они лежат.
На базе загруженных дампов создается таймлайн миграций vMotion, по которому можно перемещаться в целях анализа нескольких дампов.
Пользователи могут экспортировать результат анализа нескольких дампов в виде одного PDF-документа.
Добавлена поддержка дампов VMware vSphere 6.5 Update 2, vSphere 6.5 Update 3 и vSphere 6.7 Update 3.
Множество исправлений ошибок и улучшений движка анализа.
Воспользоваться утилитой DRS Dump Insight 1.1 можно по этой ссылке.
Многие крупные организации до сих пор используют платформу VMware vSphere 6.0 в качестве основы своей ИТ-инфраструктуры. Это обусловлено трудностями планирования апгрейда для большого парка серверов, лицензионной спецификой и в целом нежеланием трогать то, что работает хорошо.
Но надо обязательно напомнить, что 12 марта 2020 года, согласно плану, указанному в документе VMware Lifecycle Product Matrix, платформе vSphere 6.0 и гипервизору ESXi 6.0 наступает End of Life (EoL), а в терминологии VMware - End of General Support:
Согласно политикам VMware Support Policies, статус End of General Support для продуктов VMware означает, что для них перестают выпускаться существенные обновления и патчи. Поддержка по телефону также заканчивается, а с точки зрения апдейтов выпускаются только самые критичные обновления, закрывающие дырки безопасности и самые серьезные баги. То есть продукт входит в фазу Technical Guidance:
В связи с этим, пользователям vSphere 6.0 настоятельно рекомендуется провести обновление до версий vSphere 6.5 или 6.7 к этому времени. Кстати, надо отметить, что у обеих версий дата перехода в фазу Technical Guidance одна и та же - 15 ноября 2021 года:
Совместимость вашей платформы VMware vSphere 6.0, а точнее ее компонентов ESXi 6.0 и vCenter 6.0, с другими продуктами VMware вы можете проверить на специальной странице VMware Product Interoperability Matrices:
Не все администраторы виртуальной инфраструктуры VMware vSphere в курсе, что в этой платформе доступен удобный инструмент, который позволяет сгенерировать PowerCLI-сценарий из последовательности действий, которые выполняет администратор в интерфейсе vSphere Client.
Эта функция называется Code Capture, и появилась она весной прошлого года в обновлении платформы VMware vSphere 6.7 Update 2, о которой мы писали вот тут. Этот механизм VMware тестировала еще в далеком 2009 году, тогда он назывался Project Onyx.
Чтобы получить доступ к этой фиче, нужно в меню vSphere Client выбрать пункт Developer Center, где есть переключатель Enable Code Capture:
После того, как вы включите Code Capture, в верхнем тулбаре клиента появится красная кнопка записи:
Например, можно нажать на нее и, как показано на скриншоте выше, запустить клонирование виртуальной машины, а затем включить созданную ВМ.
После того, как вы запишете сессию, можно нажать кнопку Stop Recording, после чего будет сгенерирован PowerCLI-сценарий, с помощью которого можно автоматизировать развертывание новой машины:
Полученный скрипт можно скопировать или скачать для последующего его изменения уже в собственном редакторе. Надо отметить, что поскольку сценарий генерируется автоматически - он получается далеко не самым оптимальным с точки зрения структуры и времени работы. Поэтому если вы умеете разрабатывать сценарии на PowerCLI, то лучше делать их вручную с нуля. С другой стороны, не все действия в клиенте понятно, как автоматизировать, и какие командлеты использовать - поэтому Code Capture определенно может помочь подобрать нужные.
Если хочется сделать сценарий по-новой, то можно нажать кнопку "Clear and start another" - это удалит прошлый скрипт (не забудьте сохранить его, если он нужен) и начнет новую сессию записи.
Чтобы отключить функцию code capture для всех пользователей, нужно добавить строчку "codecapture.disabled=true" в файл конфигурации клиента vSphere Client (надо будет его перезапустить): /etc/vmware/vsphere-client/vsphere-client/webclient.properties.
На днях компания VMware зарелизила небольшие обновления компонентов платформы виртуализации vSphere 6.7 Update 3b. Release notes для vCenter 6.7 Update 3b можно посмотреть тут, а для ESXi 6.7 Update 3b - тут.
Нововведений особо никаких в новых апдейтах нет, в основном это фиксы подсистемы безопасности, которые регулярно выходят для всех компонентов VMware vSphere. Хотя один стоящий внимания багофикс все же есть - это исправление ошибки "After you revert a virtual machine to a snapshot, change block tracking (CBT) data might be corrupted". То есть, снова возрождался баг о том, что данные, резервируемые с использованием трекинга изменившихся блоков CBT (а это используют все системы резервного копирования), могут оказаться поврежденными.
Напомним, что прошлый апдейт пакета (vSphere 6.7 Update 3a) также не содержал существенных обновлений.
Скачать компоненты платформы VMware vSphere 6.7 Update 3b можно по этой ссылке.
Как вы знаете, недавно обновленная платформа виртуализации VMware vSphere 6.7 Update 3 стала доступной для загрузки. Одновременно с этим компания VMware сделала доступной для скачивания и развертывания систему отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. В обоих этих решениях появилась встроенная поддержка технологии Cloud Native Storage (CNS), о которой мы сегодня расскажем.
Итак, Cloud Native Storage (CNS) - это функциональность VMware vSphere и платформы оркестрации Kubernetes (K8s), которая позволяет по запросу развертывать и обслуживать хранилища для виртуальных машин, содержащих внутри себя контейнеры. По-сути, это платформа для управления жизненным циклом хранения для контейнеризованных приложений.
При этом для такого управления сделано специальное представление в интерфейсе vCenter, которое вы видите на картинке выше.
Основная задача CNS - это обеспечивать развертывание, мониторинг и управление хранилищами для Cloud Native Applications (CNA), то есть современных приложений, исполняемых в контейнерах Docker под управлением Kubernetes (но, кстати, в будущем возможна поддержка и таких платформ, как Mesos и Docker Swarm).
Архитектура CNS реализована двумя компонентами:
Интерфейс Container Storage Interface (CSI), представляющий собой плагин для K8s.
Консоль управления CNS Control Plane на сервере vCenter, доступная через vSphere Client.
Через консоль управления CNS администратор может получить представление об имеющихся хранилищах в среде K8s (и видеть маппинги хранилищ на виртуальные диски VMDK), а также управлять ими в большом масштабе, что очень сложно при оперировании на уровне отдельных контейнеров, так как их могут быть сотни на одном хосте ESXi.
Кстати, про оперирование CNS есть интересное видео от VMware:
Надо понимать, что технология CNS появилась не впервые. Ранее подобные функции реализовывал механизм vSphere Storage for Kubernetes (он же vSphere Cloud Provider, VCP). Проект VCP появился как результат внутреннего хакатона VMware, когда требовалось быстро сделать драйвер для кластеров Kubernetes.
До этого приходилось вручную монтировать хранилища контейнеров на виртуальные диски VMDK, что было крайне неудобно, а при большом количестве контейнеров - практически нереально.
Сейчас архитектура VCP реализуется такими решениями Kubernetes as a Service (KaaS), как VMware PKS, RedHat OpenShift, Google Cloud Anthos и Rancher. Для этой архитектуры было возможно 2 режима развертывания - "in-tree" и "out-of-tree". В первом случае VCP был интегрирован в дистрибутив Kubernetes и развертывался одновременно с ним, а во втором - подразумевал последующую интеграцию после развертывания K8s.
Ввиду того, что обновлять VCP при первом варианте развертывания можно было только одновременно с K8s, вариант "in-tree" был исключен из конфигурации развертывания Kubernetes. VMware использовала эту ситуацию для того, чтобы полностью переписать код VCP (который, скорее всего, был не самым оптимальным еще с хакатона) и получить новую архитектуру - CNS.
Также кстати оказалась и покупка компании Heptio (об этом мы упоминали вот тут) - в итоге VMware интегрировала решение CNS прямо в платформу vSphere, без необходимости что-либо развертывать дополнительно. Мало того, архитектура CNS поддерживает любой оркестратор контейнеров, построенный на базе спецификации CSI.
Таким образом, CNS Control Plane на сервере vCenter брокеризует соединение с плагином (на данный момент только для K8s), который уже взаимодействует на уровне Kubernetes.
Частью решения CNS являются First Class Disks (FCDs), о которых мы рассказывали вот тут. Они были придуманы для того, чтобы управлять сервисами, заключенными в VMDK-диски, но не требующими виртуальных машин для своего постоянного существования. Это очень удобно для контейнеров, так как их можно динамически привязывать и отвязывать, не оставляя после себя "осиротевших" VMDK.
Кроме всего этого, CNS полностью подчиняется политикам Storage Policy-Based Management (SPBM), а это значит, что инфраструктура таких хранилищ отлично согласуется с пространством ярусного хранения VMware vSAN и концепцией K8s StorageClass. Также CNS, конечно же, работает и с классическими хранилищами VMFS и NFS, что позволяет использовать политики SPBM на базе тэгов.
Надо отметить, что технология CNS доступна для всех пользователей VMware vSphere, начиная с издания Standard, поэтому платить отдельно за нее не придется. Ну и в заключение обзорное видео о том, что такое и как работает Cloud Native Storage:
Скачать VMware vSphere 6.7 Update 3 с интегрированной технологией CNS можно по этой ссылке.
Перед предстоящей конференцией VMworld 2019, которая состоится на следующей неделе в Сан-Франциско, компания VMware сделала несколько небольших анонсов, чтобы они не потерялись на фоне больших. В частности, стала доступной для скачивания новая версия платформы VMware vSphere 6.7 Update 3, решение VMware vSAN 6.7 Update 3 и продукт VMware PKS 1.5. Ну а на днях было выпущено еще одно обновление фреймворка для управления виртуальной инфраструктурой через PowerShell - VMware PowerCLI 11.4.
Напомним, что о прошлой версии PowerCLI 11.3 мы писали в начале лета вот тут. Давайте посмотрим, что нового появилось в PowerCLI 11.4:
В PowerCLI 11.4 был существенно доработан модуль по работе с хранилищами, чтобы поддерживать последнюю версию продукта для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Например, были обновлены командлеты Get/Set-VsanClusterConfiguration, которые теперь поддерживают функции Proactive Rebalance и vSphere Update Manager baseline preference.
Вот пример работы с этими функциями в действии (на красный текст внимание не обращайте, он говорит о том, что для работы нужен vSAN 6.7 U3):
Также появилось три новых командлета. Первый - это Add-VsanObjectToRepairQueue, он может восстанавливать объекты, которые добавляются в очередь на восстановление (ранее эта функция была частично доступна в командлете Repair-VsanObject). Второй и третий - это Get-VsanResyncingOverview и Get-VsanEnterMaintenanceMode, они работают с новыми функциями vSAN 6.7 U3.
3. Обновленный модуль HCX.
Теперь в этот модуль было добавлено целых 6 новых командлетов:
Get-HCXAppliance - возвращает информацию о текущей версии виртуального модуля и доступных версиях.
Его можно использовать с командлетом New-HCXAppliance - он позволяет проапгрейдить виртуальный модуль на одну из доступных версий.
Get-HCXContainer - добавляет возможность вывести список контейнеров типа "OrgVdc".
Get-HCXNetwork - добавляет возможность посмотреть 2 типа сетей: NsxtSegment и OrgVdcNetwork.
New-HCXNetworkExtension - дает возможность работать с сетями типа NsxtSegment.
Get-HCXServiceMesh - он имеет свойства, которые дают посмотреть параметры некоторых сервисов.
Пример использования командлетов Get-HCXAppliance и Get-HCXServiceMesh для просмотра нового свойства ServiceStatus:
Командлеты Get-HCXServiceMesh и Get-HCXInterconnectStatus были существенно доработаны, чтобы уметь исправлять ситуацию при различных ошибках. Также свойство DestinationNetworkValue теперь отображается корректно.
Как обычно, обновление модулей PowerCLI происходит командой:
На этой неделе, перед предстоящей конференцией VMworld 2019, компания VMware сделала пару интересных анонсов, а именно: было объявлено о новой версии платформы VMware vSphere 6.7 Update 3 и обновлении платформы создания отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3.
Одновременно с этим было рассказано еще об одном обновлении решения для управления инфраструктурой контейнеров приложений VMware Enterprise PKS 1.5 (Pivotal Container Service). Новый релиз построен на базе ПО Kubernetes 1.14, предназначенного для развертывания и обслуживания контейнерных сред. Напомним, что ранее мы писали о возможностях PKS версии 1.3 для облака Microsoft Azure.
Давайте посмотрим, что нового появилось в PKS 1.5:
1. Поддержка Windows-сред для контейнеров.
Пока данная возможность доступна в бета-режиме. Таким образом, теперь на платформе PKS можно одновременно управлять работой контейнеров на базе Linux и Windows. Это позволит разработчикам использовать единый стек средств разработки и фреймворки, а администраторам единые утилиты для управления контейнерами.
Более подробно о бета-программе по работе с Windows-контейнерами на платформе Kubernetes под управлением PKS можно почитать вот тут.
2. Увеличение гибкости, безопасности и прозрачности для операций с кластерами.
Тут появилось 3 значимых нововведения:
Появились новые функции по управлению кластерами Kubernetes - поддержка апгрейда отдельных кластеров, дополнительные параметры конфигурации балансировщика, а также поддержка аутентификации и авторизации на базе SAML.
Поддержка приоритизации правил фаервола с помощью секций на уровне VMware NSX-T Distributed Firewall.
Улучшилась обзорность кластеров - появились новые метрики, было добавлено больше информации о статусе и здоровье кластеров, разработчикам была предоставлена большая видимость в рамках пространств имен.
Теперь у решения есть обновленная консоль (пока в бета-режиме), которая предоставляет интуитивно понятный интерфейс при управлении кластерами Kubernetes и их компонентами:
Предыдущая версия решения позволяла выполнять функции развертывания новых кластеров, теперь также доступны и функции апгрейда и накатывания патчей. Кроме того, был упрощен онбординг пользователей - теперь можно добавить их в специальном разделе, и они сразу же получают доступ в соответствии с ролью:
4. Прочие возможности.
Новый PKS 1.5 даст администраторам и некоторые другие новые возможности, такие как постоянный IP балансировщика (это позволит использовать человекопонятные URL), а также поддержку нового релиза Harbor 1.8, где есть новые функции автоматизации интеграций, безопасности, мониторинга и поддержки репликации между реестрами.
Вчера мы писали о том, что в перед предстоящим VMworld 2019 компания VMware рассказала о новых возможностях решения для организации отказоустойчивых кластеров хранилищ VMware vSAN 6.7 Update 3. Одновременно с этим была анонсирована и новая версия главной платформы виртуализации VMware vSphere 6.7 Update 3.
Напомним, что прошлая версия - vSphere 6.7 Update 2 - вышла весной этого года. Давайте посмотрим, что нового будет в vSphere 6.7 U3:
1. Поддержка нескольких vGPU (от NVIDIA) для одной виртуальной машины.
Теперь vSphere поддерживает несколько устройств NVIDIA GRID virtual GPU (vGPU), привязанных к одной виртуальной машине. Это, прежде всего, даст возможность увеличения вычислительных мощностей для тяжелых нагрузок, предъявляющих высокие требования к расчетам графического процессора (например, задачи машинного обучения).
2. Поддержка AMD EPYC Generation 2.
Новый релиз vSphere будет полностью совместим с поколением процессоров AMD EPYC. VMware и AMD работают в тесном сотрудничестве в целях поддержки самых последних нововведений в плане безопасности и производительности, заявленных в последних моделях данной линейки CPU.
3. Возможность изменить PNID для vCenter.
Идентификатор PNID (Primary Network IDentifier) сервера vCenter Server - это его сетевое имя (оно же FQDN), которое задается на этапе установки. Теперь есть возможность изменить его прямо в интерфейсе:
4. Поддержка Dynamic DNS (DDNS).
Dynamic DNS - это механизм обновления записей DNS-серверов новыми данными при изменении IP-адресов хостов. Ранее при использовании динамических IP для vCenter Server appliance (VCSA), в случае, если адрес менялся, приходилось вручную обновлять DNS-записи (собственно, поэтому никто и не использовал динамические IP). Теперь же с поддержкой DDNS этот процесс автоматизирован.
5. Улучшения поддержки драйверов.
Для сетевого драйвера VMXNET3 версии 4 были добавлены следующие возможности:
Guest encapsulation offload and UDP (расчет контрольных сумм)
Поддержка ESP RSS для стека Enhanced Networking Stack (ENS)
Также было обновлено множество драйверов, например, в драйвере ixgben появились функции queue pairing для оптимизации производительности CPU, а в драйвере bnxtnet добавилась поддержка адаптеров Broadcom 100 GbE и потоков multi-RSS.
Вот полный список обновленных драйверов:
VMware nvme
Microchip smarpqi
Marvell qlnativefc
Broadcom lpfc/brcmfcoe
Broadcom lsi_msgpt2
Broadcom lsi_msgpt35
Broadcom lsi_msgpt3
Broadcom lsi_mr3
Intel i40en
Intel ixgben
Cisco nenic
Broadcom bnxtnet
Скорее всего, новая версия VMware vSphere 6.7 Update 3 будет доступна для скачивания либо во время VMworld 2019, либо через несколько дней после его завершения. Следите за нашими обновлениями.
Многи администраторы VMware vSphere, особенно в крупных инфраструктурах, развертывают механизм VMware vCenter HA, обеспечивающий отказоустойчивость сервера VMware vCenter (а точнее виртуальной машины vCenter или vCenter Server Appliance, vCSA). Все понимают, что vCenter / vCSA - это важнейшая часть виртуальной инфраструктуры, ведь без нее не работают такие критичные сервисы, как Site Recovery Manager, NSX и Horizon View.
Функции vCenter HA появились еще в VMware vSphere 6.5, но в vSphere 6.7 Update 1 они были существенно доработаны, а сам процесс обновления и апгрейдов vCenter упрощен. При этом управление механизмом vCenter HA полностью перешло в vSphere Client в рамках единого рабочего процесса (раньше были 2 воркфлоу - Basic и Advanced).
Давайте посмотрим, какие пути апгрейда и обновления существуют для конфигурации vCenter HA. Для начала напомним, как это выглядит:
Две машины с vCenter (активный узел и его клон - пассивный узел), а также компонент Witness образуют собой кластер, где Witness защищает от сценария Split Brain в среде vCenter HA (не путайте это с обычным vSphere HA). В случае отказа основного узла, его функции берет на себя резервный, что существенно быстрее по сравнению с восстановлением vCenter средствами стандартного HA (перезапуск на другом сервере). Это в итоге отражается на меньшем времени RTO для таких критичных сервисов, как SRM и NSX, в случае сбоев.
Перед обновлением помните, что для vCenter HA не поддерживается создание снапшотов, а значит нужно обязательно сделать File-Based Backup основного сервера vCenter перед обновлением.
Если у вас VMware vSphere 6.5, то при обновлении вы можете не разбивать кластер vCenter HA, а просто скачать ISO-образ с обновлениями (через VMware Patch Portal), либо ничего не скачивать и сразу инициировать процесс обновления из командной строки, если у вас есть доступ в интернет из компонентов кластера.
Делается все это так:
Сначала кластер vCenter HA надо перевести в режим обслуживания (maintenance mode), что не прервет репликацию, но предотвратит автоматический запуск процесса восстановления (failover).
Затем заходим на компонент Witness по SSH и запускаем его обновление из командной строки. Если у вас есть доступ в интернет на этом экземпляре vCenter, то делается это простой командой:
software-packages install --url --acceptEulas
Если же вы скачали ISO-образ с обновлениями, то делается это следующей командой:
software-packages install --iso --acceptEulas
Далее заходим на пассивный узел vCenter и там делаем то же самое.
Инициируем вручную процесс восстановления vCenter на пассивный узел (failover).
Обновляем активный узел vCenter.
Возвращаем конфигурацию в исходное состояние (failback).
Отключаем режим обслуживания (maintenance mode).
Если же у вас vCenter 6.7, то опция обновления у вас одна - отключение и удаление конфигурации HA, после чего происходит накат обновления на активном узле и повторное развертывание HA-конфигурации (такая же опция доступна и для vCenter 6.5). Этот рабочий процесс обусловлен изменениями в схеме базы данных, которые происходят в vCenter 6.7.
Начиная с vSphere 6.7 Update 1, установщик vCenter Server Upgrade installer может автоматически обнаружить присутствие кластера vCenter HA:
Далее в процессе обновления он сохранит его конфигурацию, обновит активный узел vCenter, а потом развернет его реплики для пассивного узла и узла Witness.
Надо понимать, что в процессе обновления машины с пассивным узлом и Witness будут удалены, поэтому не забудьте сделать бэкап. И сам процесс лучше проводить в ручном режиме, а не автоматическом, чтобы иметь больший контроль над получающейся итоговой конфигурацией.
Таги: VMware, vCenter, HA, vSphere, Update, Upgrade
Многие из администраторов VMware vSphere знают про механизм Storage I/O Control (SIOC) в платформе VMware vSphere (см. также наш пост здесь). Он позволяет приоритезировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены.
Сегодня мы поговорим о SIOC версии 2 и о том, как он взаимодействует с политиками Storage Policy Based Management (SPBM). Начать надо с того, что SIOC v2 полностью основан на политиках SPBM, а точнее является их частью. Он позволяет контролировать поток ввода-вывода на уровне виртуальных машин.
SIOC первой версии работает только с томами VMFS и NFS, тома VVol и RDM пока не поддерживаются. Он доступен только на уровне датасторов для регулирования потребления его ресурсов со стороны ВМ, настраиваемого на базе шар (shares). Там можно настроить SIOC на базе ограничения от пиковой пропускной способности (throughput) или заданного значения задержки (latency):
На базе выделенных shares виртуальным машинам, механизм SIOC распределит пропускную способность конкретного хранилища между ними. Их можно изменять в любой момент, перераспределяя ресурсы, а также выставлять нужные лимиты по IOPS:
Надо отметить, что SIOC v1 начинает работать только тогда, когда у датастора есть затык по производительности, и он не справляется с обработкой всех операций ввода-вывода.
Если же мы посмотрим на SIOC v2, который появился в VMware vSphere 6.5 в дополнение к первой версии, то увидим, что теперь это часть SPBM, и выделение ресурсов работает на уровне виртуальных машин, а не датасторов. SIOC v2 использует механизм vSphere APIs for I/O Filtering (VAIO), который получает прямой доступ к потоку ввода-вывода конкретной ВМ, вне зависимости от того, на каком хранилище она находится.
Таким образом, вы можете использовать SIOC v2 для регулирования потребления машиной ресурсов хранилища в любой момент, а не только в ситуации недостатка ресурсов.
Поэтому важно понимать, что SIOC v1 и SIOC v2 можно использовать одновременно, так как они касаются разных аспектов обработки потока ввода-вывода от виртуальных машин к хранилищам и обратно.
SIOC v2 включается в разделе политик SPBM, в секции Host-based rules:
На вкладке Storage I/O Control можно выбрать предопределенный шаблон выделения ресурсов I/O, либо кастомно задать его:
Для выбранной политики можно установить кастомные значения limit, reservation и shares. Если говорить о предопределенных шаблонах, то вот так они выглядят для варианта Low:
Так для Normal:
А так для High:
Если выберите вариант Custom, то дефолтно там будут такие значения:
Лимит можно задать, например, для тестовых машин, где ведется разработка, резервирование - когда вы точно знаете, какое минимальное число IOPS нужно приложению для работы, а shares можете регулировать долями от 1000. Например, если у вас 5 машин, то вы можете распределить shares как 300, 200, 100, 100 и 100. Это значит, что первая машина будет выжимать в три раза больше IOPS, чем последняя.
Еще один плюс такого назначения параметров SIOC на уровне ВМ - это возможность определить политики для отдельных дисков VMDK, на которых может происходить работа с данными разной степени интенсивности:
После того, как вы настроили политики SIOC v2, вы можете увидеть все текущие назначения в разделе Monitor -> Resource Allocation -> Storage:
Не так давно мы писали о новых возможностях последней версии платформы виртуализации VMware vSphere 6.7 Update 2. Одним из нововведений стал улучшенный интерфейс управления плагинами (Plugin Management UI), который дает пользователю полный контроль над процессами обновления и развертывания плагинов к vSphere.
Если еще в Update 1 при установке нового плагина или обновлении старого, в случае неудачи процесс просто завершался, и приходилось смотреть в файл журнала, то теперь для этого есть графическое представление с выводом информации о возникших проблемах (например, несовместимость с новой версией платформы).
В подразделе Client Plug-ins раздела Administrator теперь приведены все клиентские зарегистрированные плагины на любом из серверов vCenter в вашем окружении. Также у этих плагинов есть статусы: In Progress, Deployed, Failed или Incompatible.
Статусы Failed и Incompatible являются кликабельными - при нажатии на них всплывет подсказка с возможной причиной возникновения подобных ошибок или причины несовместимости (при возможности будет также приведен участок лога):
В процессе инсталляции плагин проходит через несколько фаз, которые отслеживаются сервером vCenter, также их можно получать через TaskManager API (его могут использовать и сторонние разработчики). Выполняемые задачи отображаются на сервере vCenter в 3 разделах:
Панель Recent Tasks в нижней части клиента
Консоль в разделе задач (Task Console)
Просмотр представления Tasks для выбранного объекта vCenter Server
Задачи создаются и отслеживаются на сервере vCenter, к которому в данный момент подключен vSphere Client. Если же виртуальная среда работает в режиме федерации Enhanced Linked Mode, то задачи по развертыванию плагина создаются на всех подключенных серверах vCenter. Поэтому любой экземпляр vSphere Client будет видеть эти задачи.
Как происходит работа с плагинами
При логине пользователя в vSphere Client, все плагины vCenter загружаются в кэшированную папку самого клиента на сервере vCenter. Для отслеживания этого процесса создается задача "Download plug-in". Если загрузка плагина прошла успешно, то он становится доступным для развертывания, что видно в консоли задач. И это значит, что он был загружен в кэшированную папку.
Следующая фаза - это задача "Deploy plug-in", которая стартует следующей. Если она завершается успешно, это значит, что плагин установлен и доступен для использования со стороны vSphere Client. Кстати, если задача Download plug-in прошла с ошибкой, то и задача Deploy plug-in будет пропущена.
Ошибки плагинов при развертывании теперь детально описаны в консоли:
Также иногда к ошибке прилагается лог развертывания, например, в случае, когда их вызвало стороннее программное обеспечение, отдающее некоторый лог ошибки.
В случае апгрейда плагина этот процесс представляется набором из трех задач: "Download plug-in", "Undeploy plug-in" и "Deploy plug-in". После этого в vSphere Client появляется глобальная нотификация о новой версии развернутого плагина и с просьбой сделать рефреш в браузере, чтобы плагин начал работать.
Один сервер vCenter может работать только с одной версией плагина, но в архитектурах Enhanced Linked Mode и Hybrid Linked Mode может быть несколько серверов vCenter, каждый из которых может содержать свою версию плагина.
В этом случае vSphere Client обрабатывает плагины двумя способами:
Local plug-in architecture - в этом случае оперирование происходит с самой новой версией плагина, обнаруженной на всех доступных серверах vCenter. При этом все остальные версии плагина игнорируются. Если обнаруживается более новая версия плагина на одном из серверов vCenter - происходит ее апгрейд.
Remote plug-in architecture - она появилась в vSphere 6.7 Update 1. В этом случае происходит поддержка своей версии плагина на уровне того сервера vCenter, с которым происходит оперирование со стороны vSphere Client. Такое поведение используется, например, в среде Hybrid Linked Mode, где версии плагинов и серверов vCenter могут отличаться очень значительно. В этом случае все версии плагина скачиваются с соответствующих экземпляров vCenter и работа со стороны vSphere Client происходит с каждой версией как с независимым плагином.
Ну и напоследок приведем статусы, которые могут возникать при развертывании и апгрейде плагинов:
In progress
Плагин находится в стадии развертывания.
Deployed
Плагин установлен и доступен для использования через интерфейс vSphere Client.
Failed
Показывается при невозможности скачать или установить плагин:
Download error
Установка из незащищенного места - используется http вместо https.
Невозможно получить URL плагина.
vSphere Client не авторизован для скачивания плагина.
Packaging error
Поврежден zip-пакет плагина.
Отсутствует файл манифеста.
Отсутствует папка plugins.
Отсутствуют необходимые бандлы в плагине.
Deployment error
Ошибка связей (Dependency error) при развертывании плагина на vSphere Client.
На днях компания VMware выпустила третий пакет обновления для предыдущего поколения своей главной платформы виртуализации - VMware vSphere 6.5 Update 3. Напомним, что Update 2 вышел в мае прошлого года, так что давно было уже пора выпускать апдейт, так как версия 6.5 по-прежнему широко используется, особенно в крупных предприятиях.
Давайте посмотрим, что нового в vSphere 6.5 U3.
Новые функции vCenter 6.5 Update 3:
События о добавлении, удалении и модификации пользовательских ролей содержат информацию о пользователе, который производит изменения.
Улучшения возможностей аудита в компоненте VMware vCenter Single Sign-On - теперь появились события для следующих операций: управление пользователями, логин, создание групп, изменение источника идентификации, управление политиками. Доступна эта фича только для виртуального модуля vCSA с интегрированным Platform Services Controller. Поддерживаемые источники идентификации: vsphere.local, Integrated Windows Authentication (IWA) и Active Directory over LDAP.
Поддержка новых внешних баз данных - добавлена поддержка Microsoft SQL Server 2014 SP3.
Драйвер ixgben добавляет функцию queue pairing для оптимизации эффективности CPU.
С помощью ESXi 6.5 Update 3 вы можете отслеживать использование лицензий и обновлять топологию коммутаторов. Также улучшения можно увидеть в Developer Center клиента vSphere Client.
Поддержка устаревших серверов AMD Zen 2.
Множество обновлений драйверов устройств: lsi-msgpt2, lsi-msgpt35, lsi-mr3, lpfc/brcmfcoe, qlnativefc, smartpqi, nvme, nenic, ixgben, i40en и bnxtnet.
Поддержка Windows Server Failover Clustering и Windows Server 2019.
Добавлено свойство com.vmware.etherswitch.ipfixbehavior в распределенные виртуальные коммутаторы, чтобы позволить пользователям выбирать способ трекинга входящего и исходящего трафика. Значение 1 включает сэмплирование для входящего и исходящего трафика, значение 0 включает его только для исходящего (значение по умолчанию).
Если вы ожидали среди возможностей чего-то действительно нового - увы, этого не бывает. VMware надо развивать ветку vSphere 6.7 и следующие версии платформы. Скачать VMware vSphere 6.5 Update 3 можно по этой ссылке.
Какие еще продукты VMware были обновлены параллельно с этим релизом:
Как знают почти все администраторы платформы VMware vSphere, для кластеров VMware HA/DRS есть такой режим работы, как Enhanced vMotion Compatibility (EVC). Нужен он для того, чтобы настроить презентацию инструкций процессора (CPU) хостами ESXi так, чтобы они в рамках кластера соответствовали одному базовому уровню (то есть все функции процессоров приводятся к минимальному уровню с набором инструкций, которые гарантированно есть на всех хостах).
Ввели режим EVC еще очень давно, чтобы поддерживать кластеры VMware vSphere, где стоят хосты с процессорами разных поколений. Эта ситуация случается довольно часто, так как клиенты VMware строят, например, кластер из 8 хостов, а потом докупают еще 4 через год-два. Понятно, что процессоры уже получаются другие, что дает mixed-окружение, где по-прежнему надо перемещать машины между хостами средствами vMotion. И если набор презентуемых инструкций CPU будет разный - двигать машины между хостами будет проблематично.
EVC маскирует инструкции CPU, которые есть не на всех хостах, от гостевых ОС виртуальных машин средствами интерфейса CPUID, который можно назвать "API для CPU". В статье VMware KB 1005764 можно почитать о том, как в кластере EVC происходит работа с базовыми уровнями CPU, а также о том, какие режимы для каких процессоров используются.
Надо отметить, что согласно опросам VMware, режим кластера EVC используют более 80% пользователей:
В VMware vSphere 6.7 появились механизмы Cross-Cloud Cold и Hot Migration, которые позволяют переносить нагрузки в онлайн и офлайн режиме между облаками и онпремизной инфраструктурой.
Когда это происходит, виртуальной машине приходится перемещаться между хостами с разными наборами инструкций процессора. Поэтому, в связи с распространением распределенных облачных инфраструктур, в vSphere появилась технология Per-VM EVC, которая позволяет подготовить виртуальную машину к миграции на совершенно другое оборудование.
По умолчанию, при перемещении машины между кластерами она теряет свою конфигурацию EVC, но в конфигурации ВМ можно настроить необходимый базовый уровень EVC, чтобы он был привязан к машине и переезжал вместе с ней между кластерами:
Обратите внимание, что Per-VM EVC доступна только, начиная с vSphere 6.7 и версии виртуального железа Hardware Version 14. Эта конфигурация сохраняется в vmx-файле (потому и переезжает вместе с машиной) и выглядит следующим образом:
Некоторые пользователи не включают EVC, так как покупают унифицированное оборудование, но VMware рекомендует включать EVC в кластерах со старта, так как, во-первых, никто не знает, какое оборудование будет докупаться в будущем, а, во-вторых, так будет легче обеспечивать миграцию виртуальных машин между облачными инфраструктурами.
Основная причина, по которой не включают EVC - это боязнь того, что поскольку машины не будут использовать весь набор инструкций CPU (особенно самых последних), то это даст снижение производительности. Поэтому VMware написала целый документ "Impact of Enhanced vMotion Compatibility on Application Performance", где пытается доказать, что это не сильно влияет на производительность. Вот, например, производительность Oracle на выставленных базовых уровнях для разных поколений процессоров (в документе есть еще много интересных графиков):
Чтобы включить EVC на базе виртуальной машины, нужно ее выключить, после чего настроить нужный базовый уровень. Для автоматизации этого процесса лучше использовать PowerCLI, а сама процедура отлично описана в статье "Configuring Per-VM EVC with PowerCLI".
Для того, чтобы выяснить, какие базовые уровни EVC выставлены для виртуальных машин в кластере, можно использовать следующий сценарий PowerCLI:
Get-VM | Select Name,HardwareVersion,
@{Name='VM_EVC_Mode';Expression={$_.ExtensionData.Runtime.MinRequiredEVCModeKey}},
@{Name='Cluster_Name';Expression={$_.VMHost.Parent}},
@{Name='Cluster_EVC_Mode';Expression={$_.VMHost.Parent.EVCMode}} | ft
Это даст примерно следующий результат (надо помнить, что отчет будет сгенерирован только для VM hardware version 14 и позднее):
В примере выше одна машина отличается от базового уровня хостов, но в данном случае это поддерживаемая конфигурация. Проблемы начинаются, когда машина использует более высокий базовый уровень CPU, чем его поддерживает хост ESXi. В этом случае при миграции vMotion пользователь получит ошибку:
Понять максимально поддерживаемый режим EVC на хосте можно с помощью команды:
В целом тут совет такой - включайте режим Enhanced vMotion Compatibility (EVC) в кластерах и для виртуальных машин VMware vSphere сейчас, чтобы не столкнуться с неожиданными проблемами в будущем.
Начиная с VMware vSphere 6.7, компания VMware поддерживает технологию защищенной виртуализации Virtualization-Based Security (VBS). Это один из механизмов, который позволяет предоставлять пользователям более защищенные рабочие Windows-среды средствами технологий Device Guard и Credential Guard (последняя предназначена для изоляции пространства хранения учетных записей от потенциальной кражи вредоносным ПО). Эти функции очень важны для защиты, например, таких компонентов инфраструктуры, как серверы Active Directory.
Между тем, с виртуальными машинами, работающими с поддержкой данной технологии, была найдена серьезная проблема - они зависают или выпадают в синий экран смерти (BSOD) при загрузке. Баг проявляется при включенной технологии VBS (на скриншоте vSphere Client на базе HTML5 с Hardware Version 14):
Также этот баг актуален и для включенной поддержки технологии I/O MMU:
Возможность VBS доступна в Microsoft Windows 10/2016/2019, сам же баг стал проявляться, начиная с версии Windows Insider Build 18362. VMware говорит, что проблема находится на стороне Microsoft, но оба вендора совместно работают над выпуском патча для ОС.
Статья базы знаний VMware KB 68043 содержит вопросы, которые позволят вам определить, затрагивает ли вас проблема.
Помимо проверки настроек в интерфейсе vSphere Client, которые вы видите на скриншотах выше, можно использовать вот такой PowerCLI-скрипт для определения машин, которые затрагивает проблема:
После того, как вы найдете у себя такие ВМ, то выхода у вас два:
Не использовать VBS и I/O MMU для виртуальных машин.
Использовать workaround, который приведен в статье KB 68043.
Workaround заключается в следующем:
Выключаем машину и отключаем VBS и I/O MMU для нее.
Устанавливаем ОС на ВМ или обновляем ее до самых последних апдейтов.
Выключаем ВМ, выбираем в настройках "Expose hardware assisted virtualization to guest".
Включаем ВМ, в настройках включаем функцию (feature) "Hyper-V" в гостевой ОС, после чего перезагружаем машину.
Опять выключаем ВМ и включаем VBS и/или I/O MMU, после чего она уже будет нормально работать.
Помните, что такой Workaround не вечен для свежих установок, например, из образов 1903 & 19H1 DVD/ISO, так как следующее обновление потенциально может вернуть баг, который еще не пофикшен со стороны Microsoft. Имейте это в виду, когда создаете шаблоны виртуальных машин для массового развертывания. Поэтому сначала все обновляем до самой последней версии, потом уже используем Workaround выше.
Кстати, все могло бы быть и хуже) Например, уязвимость Remote Desktop Services vulnerability (CVE-2019-0708), требующая немедленного обновления не затрагивает системы с описанной проблемой выпадения в BSOD. Уязвимость с удаленным рабочим столом актуальна только для систем Windows XP, 7, Windows Server 2003, 2008 (+ R2), а баг с зависанием актуален только для более поздних Windows.
Ждем пока сделают нормальный фикс, и не надо будет плясать с Workaround'ом. А пока можете на всякий случай отключить VBS, если позволяют корпоративные политики.
Некоторое время назад мы писали о новых возможностях недавно вышедшего обновления платформы виртуализации VMware vSphere Platinum 6.7 Update 2. Cреди новых возможностей гипервизора там есть фича "Новые возможности планировщика CPU помогают бороться с уязвимостями типа L1TF".
Оказывается, это довольно серьезное улучшение. Надо сказать, что планировщик гипервизора side-channel aware scheduler (SCA) появился еще в прошлой версии платформы. Он закрывал уязвимость L1TF (L1 Terminal Fault) в процессорах Intel за счет того, что процессы виртуальных машин запускались только в одном треде одного физического ядра. Это позволяло нивелировать вектор атаки данного типа, но приводило к существенному снижению производительности.
Особенно это чувствовалось, когда сервер ESXi был загружен по CPU полностью, и SCA первой версии в этом случае давал до 30% хуже результат, чем без него. Если же сервер был загружен, например, на 75%, то в производительность оставалась примерно той же, но без SCA нагрузка на CPU была существенно ниже.
Итак, начиная с VMware vSphere 6.7 Update 2, появился обновленный планировщик SCAv2, который был существенно доработан по сравнению со своей предыдущей версией. Он позволяет исполнять контексты vCPU одной машины в разных гипертредах одного физического ядра процессора хоста. В этом случае атаке L1TF не подвержены взаимодействия типа VM/VM и VM/ESXi (чувствительная информация между ними не шарится в общем кэше).
В документе описано 2 типа тестов, которые проводились для планировщиков SCAv1 и SCAv2: работа хоста под максимальной нагрузкой по процессорам и под нагрузкой на уровне 75% от максимальной мощности всех CPU хоста ESXi (reduced load). В качестве базового уровня использовался планировщик без SCA (он же на картинке ниже обозначен как Default):
Если верить графикам, отражающим результаты тестирования различными бенчмарками, то планировщик SCAv2 работает существенно лучше во всех случаях, кроме очень большой (по выделенным ресурсам) виртуальной машины - Monster VM с базой Oracle и 192 vCPU, но такой кейс в реальной жизни случается весьма редко. Так что, в целом, улучшения были проведены весьма существенные (как минимум, на 11% планировщик стал более производительным по результатам тестов).
Помимо документа выше, информация об улучшениях планировщика приведена еще в KB 55806.
RSS
