Как многие из вас знают, в ноябре прошлого года компания VMware отозвала обновление платформы vSphere 7 Update 3 из-за критических ошибок. Это были проблемы с выпадением в PSOD, трудности при апгрейде с прошлых версий, неполадки в плане стабильности vSphere HA и другое.

В конце декабря мы напомнили о том, что проблема существует уже месяц, а VMware все никак не может решить ее. Основная информация о возникшей ситуации с последним пакетом обновлений публиковалась в KB 86398. Там же можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281.

Теперь VMware объявила о выпуске окончательной версии VMware vSphere 7 Update 3c, где все должно работать как надо (однако бежать обновляться прямо сейчас мы бы не рекомендовали:)

Также сообщается, что в новом релизе решены все проблемы с безопасностью, касающиеся уязвимости Log4j, которая затронула большое количество систем. Эта уязвимость позволяла злоумышленнику, который имел доступ к отсылке логов (самих сообщений или к настройке их параметров), исполнять код, полученный с LDAP-серверов, когда настройка message lookup substitution включена.

Наконец-то были обновлены основные компоненты продукта, ESXi и vCenter, а также опубликован список известных проблем и их обхода:

• vSphere ESXi 7 Update 3c Release Notes
• vCenter Server 7 Update 3c Release Notes
• vSphere 7 Update 3c – List of Known Issues and Workarounds

О новых возможностях основного vSphere 7 Update 3 вы можете почитать у нас тут, их список не изменился. Скачать все компоненты платформы, включая ESXi 7 Update 3c и vCenter Server 7 Update 3c, вы можете по этой ссылке.

Дункан написал хорошую разъясняющую статью про загрузку ESXi с SD-карты и размещение раздела OSDATA на хранилище в SAN. Напомним, что мы писали о том, что VMware уходит от механизма загрузки ESXi с SD-карт ввиду их низкой надежности и неприспособленности под задачи гипервизора.

Как знают администраторы VMware vSphere, начиная с седьмой версии платформы, структура разделов ESXi теперь выглядит следующим образом:

Как мы видим, все основные разделы, не относящиеся к загрузке переехали в раздел ESX-OSDATA. Многие администраторы хотели бы хранить загрузочный раздел локально на SD-карте, а OSDATA - в сети SAN.

К сожалению, это не поддерживается.

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

Действительно, тут как бы есть пункт, что при загрузке ESXi можно использовать SD-карту для Bootbank, а Managed FCoE/iSCSI LUN для OSDATA (но обратите внимание, что это Locally attached devices). Реально же FCoE, iSCSI и FC для загрузки ESXi с SAN можно использовать только тогда, когда и OSDATA, и Bootbank находятся на SAN-устройстве.

Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.8. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.

Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.8:

• Исправление для ACPI, что позволяет поддерживать гостевые ОС OpenBSD.
• Улучшенная обработка ITS device ID width в реализации без поддержки indirect table.
• Улучшенная обработка VMkernel TLB (Translation Lookaside Buffer - он представляет собой кэш для MMU).
• Улучшенная обработка механизма NUMA, особенно в части сообщений об ошибках.

Скачать VMware ESXi ARM Edition 1.8 можно по этой ссылке. Напомним, что апгрейд с прошлых версий этого гипервизора не поддерживается, каждую новую версию нужно устанавливать заново.

В конце ноября мы писали о том, что "уже 5 дней VMware находится в состоянии экстренной починки VMware vSphere 7 Update 3", но ситуация оказалась гораздо хуже. Никаких новостей об исправлениях для новой версии, по-прежнему, нет. Напомним, что о новых возможностях vSphere 7 U3 мы писали тут.

Основная информация о возникшей ситуации с последним пакетом обновлений приведена в KB 86398. Там можно узнать, что вся линейка Update 3/3a/3b была отозвана из-за критических проблем, описанных в KB 86287 и KB 86281. На странице загрузки VMware vSphere, по-прежнему, висит красный баннер и релиз Update 2a от апреля этого года:

Среди найденных багов - и выпадение в PSOD, и проблемы апгрейда с прошлых версий, и проблемы со стабильностью vSphere HA, и многое другое, судя по заметкам в некоторых блогах:

Если мы зайдем на статью базы знаний "Build numbers and versions of VMware ESXi/ESX (2143832)", то увидим, что последние три релиза vSphere просто зачеркнуты в таблице:

18 ноября зачеркнутые в таблице релизы были удалены из VMware Customer Connect, а новостей по поводу сроков исправления проблем с этого времени не было. Сама VMware пишет в KB вот так:

Надо отметить, что VMware vCenter 7 Update 3 и Update 3a сейчас доступны для скачивания и использования в производственной среде.

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

Ждем исправлений!

Как знают многие администраторы VMware vSphere, у компании есть очень полезный документ "Security Configuration Guide", который представляет собой основное руководство по обеспечению безопасности виртуальной среды. Последняя версия этого документа содержит 87 настроек (мы писали об этом тут), так или иначе влияющих на безопасность как самой платформы виртуализации, так и виртуальных машин и их гостевых операционных систем.

Документ передает концепцию "Secure by design", что означает, что среда VMware vSphere изначально настроена оптимальным образом с точки зрения безопасности, поэтому вносить изменения вам нужно только в случае наличия каких-либо специальных требований именно в вашей инфраструктуре.

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

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

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

Структура списка конфигураций и рекомендаций

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

• Guideline ID - идентификационное имя рекомендации.
• Description - лаконичная формулировка сути этой рекомендации.
• Discussion - описание влияния настройки на конфигурацию среды и операции, а также обсуждение моментов, которые касаются удобства использования инструментов управления в связи с изменением настройки.
• Configuration Parameter - это название расширенной настройки соответствующего компонента, которую вы можете изменить. Понятно дело, что эта колонка заполнена не всегда, так как есть рекомендации, которые регулируются не конкретными настройками, а, например, топологией или подходом к организации среды.
• Desired value - рекомендуемое значение, часто оно является значением по умолчанию, если это не site specific.
• Default value - то значение, которое установлено по умолчанию.
• Is Desired Value the Default? - просто для понимания (и для референса в будущем), установлено ли желаемое значение по умолчанию.
• Action Needed - это тип действия, который необходимо предпринять - изменить настройку, проверить конфигурацию или топологию, добавить или удалить что-то и т.п.
• Setting Location in vSphere Client - очень полезная колонка, позволяющая вам найти нужную настройку в клиенте vSphere.
• Negative Functional Impact in Change From Default? - это как раз информация о влиянии на функционал в случае изменения настройки.
• PowerCLI Command Assessment - команда PowerCLI, с помощью которой можно узнать текущее значение настройки.
• PowerCLI Command Remediation Example - команда PowerCLI по применению настройки.
• Hardening - указывает на то, что это действительно настройка, которой нужно уделить внимание при конфигурации.
• Site Specific Setting - говорит о том, что задать конфигурацию должен сам пользователь, в зависимости от его окружения.
• Audit Setting - указывает, что вам необходимо время от времени проверять эту настройку, чтобы убедиться, что значение по умолчанию не было изменено необоснованно.

Само руководство разбито на 4 категории, которые понятны всем администраторам:

• Хосты ESXi
• Сервер vCenter
• Виртуальные машины
• Гостевые ОС виртуальных машин

Также в документе есть и вкладка "Deprecated" - там находятся те настройки, которые больше не актуальны. Что важно - там помечено, почему это случилось (в колонке Discussion).

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

Хосты ESXi

• Configure remote logging - это действительно правильная рекомендация. Хосты ESXi должны отправлять свои логи на удаленный сервер Syslog. Самый удобный вариант - это использовать в качестве Syslog-сервера решение VMware vRealize Log Insight. Ведь если злоумышленник проникнет на сервер ESXi, то после своей активности он эти логи удалит, и расследовать будет нечего. С централизованного внешнего сервера удалить эти данные сложнее. На работу виртуальной среды эта конфигурация не влияет.
• Ensure ESXi management interfaces are isolated on their own network segment - это очевидная, но не всегда выполняемая администраторами конфигурация. Конечно же, вся управляющая инфраструктура виртуальной среды должна находиться в выделенном сегменте сети в своих VLAN, куда имеют доступ только администраторы. То же самое касается и сети vMotion, и сети vSAN.
• esxi-7.shell-interactive-timeout и esxi-7.shell-timeout (Set a timeout to automatically terminate idle ESXi Shell and SSH sessions) - по умолчанию сессии командной оболочки и SSH-сессии висят постоянно, что, конечно же, представляет потенциальную угрозу. Лучше ограничить таймаут 600 секундами, чтобы никто эти сессии не смог подхватить.
• Only run binaries delivered via VIB - эта настройка позволяет устанавливать бинарные компоненты только через VIB-пакеты, которые соответствуют установленному Acceptance Level. Если вы не пользуетесь посторонними библиотеками кустарного производства, то лучше эту настройку включить. Когда вам понадобится установить такой бинарник - просто включите эту настройку снова. Но это изменение лучше задокументировать.
• Enable bidirectional/mutual CHAP authentication for iSCSI traffic - настраивать CHAP-аутентификацию нужно обязательно, чтобы предотвратить атаки, связанные с перехватом трафика к хранилищам. Настраивать это недолго, но зато будет больше уверенности в сохранности данных.

Сервер vCenter

• Ensure vCenter Server management interfaces are isolated on their own network segment or as part of an isolated ESXi management network - это та же самая рекомендация по изоляции управляющей сети от сети виртуальных машин, что и для серверов ESXi. Убедитесь, что они надежно разделены с помощью VLAN и других техник.
• Ensure that port mirroring is being used legitimately - эта настройка отключена по умолчанию, но зеркалирование трафика на портах vSphere Distributed Switch надо периодически проверять (vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> Port Mirroring). Такой способ атаки - один из самых простых в реализации, если у злоумышленника есть доступ к настройкам VDS (обычно в них никто не заглядывает после первичной настройки). То же самое касается и отправки трафика NetFlow, управление которым производится в разделе vSphere Client -> Networking -> Distributed Switch -> Configure -> Settings -> NetFlow.
• Limit access to vCenter Server by restricting DCLI / SSH - это разумная рекомендация, чтобы злоумышленник не смог залогиниться в консоль виртуального модуля напрямую или по SSH. Уменьшив поверхность атаки, вы сделаете среду более защищенной. Только не забудьте задокументировать это изменение.
• Configure File-Based Backup and Recovery - не ленитесь настраивать и обслуживать бэкап конфигурации вашего управляющего сервера. Однажды это может вам пригодиться как в контексте безопасности, так и в контексте быстрого восстановления системы управления в виртуальной инфраструктуре в случае сбоя.
• Configure remote logging - здесь те же рекомендации, что и для ESXi. Не ленитесь настраивать сервер удаленного сбора логов.

Виртуальные машины

• Limit the number of console connections - очень часто к консоли виртуальной машины не нужно больше одного подключения ее администратора. В этом случае дефолтное количество 40 одновременных подключений лучше уменьшить до 1. Делается это в разделе VM -> Edit Settings -> VM Options -> VMware Remote Console Options.
• Encrypt VMs during vMotion - это полезная настройка. По умолчанию, трафик vMotion шифруется, только если есть такая возможность (Opportunistic). Если у вас хватает вычислительных ресурсов и быстрая сеть, то можно установить это значение в "Required". Это обеспечит защиту от перехвата трафика vMotion, в котором есть данные гостевой ОС виртуальной машины.
• Lock the VM guest session when the remote console is disconnected - лучше включить эту настройку и лочить сессию при отключении удаленной консоли, чтобы брошенная администратором сессия в гостевой ОС виртуальной машины не была подхвачена злоумышленником. На удобство работы это не сильно влияет. Изменить эту настройку можно в VM -> Edit Settings -> VM Options -> VMware Remote Console Options.

Гостевая ОС

• Ensure that VMware Tools are updated - это просто еще одно напоминание, что нужно постоянно следить за тем, что пакет VMware Tools обновлен до последней версии (и желательно поддерживать единый уровень версий для всех машин). В нем содержится много компонентов (кстати, не устанавливайте ненужные), поэтому уязвимость в одном из них может скомпрометировать множество виртуальных машин. То же самое относится и к версии Virtual Hardware - следите за этим.
• Disable Appinfo information gathering - об интерфейсе Appinfo мы писали вот тут (он же Application Discovery). Он позволяет, например, собирать информацию о запущенных приложениях внутри гостевой системы и их параметрах. Механизм Appinfo используется различными решениями, такими как vRealize Operations Manager, для мониторинга на уровне гостевой ОС. Если же вы не используете эти решения в своей виртуальной среде, то данный механизм лучше просто отключить через VMware Tools. Учитывая какое количество багов, касающихся безопасности, в последнее время находится в различных компонентах инфраструктурного ПО, лучше отключить функции Appinfo, которые включены по умолчанию для всех гостевых ОС после установки VMware Tools.

Конечно же, в документе vSphere 7 Security Configuration Guide есть много и других настроек и конфигураций, изменение которых помогут вам повысить уровень безопасности. Иногда это связано с требованиями регулирующих органов или спецификой внутренних политик организации. Поэтому обратите особенное внимание на те конфигурации, которые помечены как Site Specific, а также те, где рекомендуемые значения отличаются от дефолтных. И обязательно документируйте сделанные изменения, а также проводите регулярный аудит наиболее важных настроек.

Компания VMware на сайте проекта Labs сделала доступной новую версию платформы виртуализации ESXi ARM Edition 1.7. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). Также этот гипервизор в будущем найдет свое применение в таких платформах, как Project Monterey. О прошлой версии ESXi для ARM мы писали вот тут.

Давайте посмотрим, что нового появилось в ESXi ARM Edition 1.7:

• Экспериментальная поддержка платы Quartz64 от Pine64.
• Поддержка драйвера VMware SVGA (теперь он совместим с платой Fusion on AS, где исправлены многие ошибки)
• Монитор виртуальных машин, который поддерживает архитектуру NUMA, что улучшает производительность на двухсокетных машинах Ampere Altra.
• Улучшенная совместимость для систем без IORT.
• Исправлены проблемы с производительностью в гостевых ОС с новыми ядрами Linux, такими как Debian 10 и Photon 4.
• Добавлено распознавание ядра Cortex-A55.
• Улучшенная обработка TLBI в мониторе виртуальных машин и в VMkernel.
• Улучшения обработки одновременных базовых операций в гипервизоре.

Скачать VMware ESXi ARM Edition 1.7 можно по этой ссылке.

Как все из вас знают, не так давно компания VMware выпустила обновление своей серверной платформы виртуализации vSphere 7 Update 3. Мы писали также о нововведениях в отношении хранилищ, обновлении 3a, новых возможностях продукта vSAN 7 U3 и обновлениях vCenter и vSphere Client.

Сегодня мы поговорим об улучшениях в плане производительности платформы VMware vSphere 7 Update 3, о которых рассказано в обновившемся недавно документе "What’s New in Performance for VMware vSphere 7?". О похожем документе о производительности платформы vSphere 7 Update 2 мы писали в начале осени тут.

Давайте посмотрим, что нового в vSphere 7 U3 в плане производительности:

1. Масштабируемость виртуальных машин

Теперь максимальные параметры ВМ, доступных в vSphere выглядят так:

2. Оптимизации рабочих нагрузок, чувствительных к задержкам

Гипервизор VMware ESXi был еще больше оптимизирован, чтобы быстрее исполнять приложения, чувствительные ко времени отклика и задержкам (ultra-low-latency applications), уменьшены jitter и interference для приложений реального времени. Для этого было сделано множество оптимизаций в плане обработки прерываний. Чтобы воспользоваться этой функцией (low-latency mode) ее надо включить в BIOS машины.

3. Технология vSphere Memory Monitoring and Remediation (vMMR)

Размер памяти DRAM влияет на 50-60% стоимости самого сервера. При этом 1TB DRAM - это уже 75% этой стоимости. Поэтому VMware давно борется с этим, и одна из возможных оптимизаций здесь - использование Intel Optane Persistent Memory Mode, когда железо использует DRAM как кэш и представляет PMem как основную память системы. PMem более дешевая технология, но имеет побольше задержки (latency).

С помощью vSphere Memory Monitoring and Remediation (vMMR) можно следить за работой памяти в режиме Intel PMem Memory Mode и получать алерты когда ESXi исчерпывает память DRAM, что может привести к падению производительности сервера.

4. NVMe over TCP/IP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании при поддержании высокого уровня производительности.

Больше подробностей о производительности VMware vSphere 7 вы найдете в документе "What’s New in Performance for VMware vSphere 7?".

Недавно мы писали об обновлении на сайте проекта VMware Labs пакета Community Networking Driver for ESXi до версии 1.2.2, который представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. На днях на сайте Labs вышли обновления еще двух пакетов драйверов.

1. NVMe Driver for ESXi версии 1.2

Это набор драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах. О прошлой версии мы писали вот тут, а в новой версии нововведение только одно - поддержка ESXi 7.0 и более новых версий гипервизора для устройств Apple NVMe (это Apple 2018 Intel Mac Mini 8.1 или Apple 2019 Intel Mac Pro 7.1).

Скачать пакет драйверов Community NVMe Driver for ESXi 1.2 можно по этой ссылке.

2. USB Network Native Driver for ESXi версии 1.9

Это нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этих драйверов мы писали вот тут.

В версии пакета драйверов 1.9 появились следующие нововведения:

• Добавлена поддержка ESXi 7.0 Update 3
• Добавлена поддержка VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100 (VID=VendorID, PID = ProductID)
• Исправлена проблема с функциями управления питанием для xHCI
• По умолчанию функция USB bus scanning отключается (настройка usbBusFullScanOnBootEnabled=0), чтобы не вызывать розовый экран смерти (PSOD) для пользователей, которые используют несколько карточек USB NIC.

Таблица поддерживаемых устройств теперь выглядит так:

Скачать USB Network Native Driver for ESXi версии 1.9 можно по этой ссылке (не забудьте корректно указать вашу версию ESXi при загрузке).

На сайте проекта VMware Labs появилось еще одно полезное средство для администраторов виртуальной инфраструктуры - vSphere Diagnostic Tool. Оно представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi.

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

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

Для vCenter Server Appliance 6.5 или более поздней версии можно выполнить следующие тесты:

• Базовая информация о vCenter
• Проверка Lookup Service
• Проверка AD
• Проверка сертификатов vCenter
• Проверка основных файлов (Core File)
• Проверка диска
• Проверка vCenter DNS
• Проверка vCenter NTP
• Проверка портов vCenter
• Проверка аккаунта Root
• Проверка служб vCenter
• Проверка механизма VCHA

В качестве результатов будет выдан один из статусов Pass/Warning/Fail, а также для статусов Warning и Fail выводятся ссылки на статьи KB, которые могут пригодиться для решения проблем в данной категории.

Команда заявляет, что в бэклоге проекта еще более 100 планируемых фич, поэтому следите за обновлениями скриптов. Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).

Скачать vSphere Diagnostic Tool можно по этой ссылке.

Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...

На сайте VMware Labs в последнее время вышло несколько обновлений интересных утилит, таких как SDDC Import/Export for VMware Cloud on AWS, App Volumes Migration Utility и HCIBench. Также мы писали о новом продукте Workspace ONE Policy Analyzer for Windows, но сегодня расскажем об обновлении Community Networking Driver for ESXi версии 1.2.2.

Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. О прошлой версии этих драйверов мы писали весной этого года вот тут. В данном обновлении были добавлены драйверы для устройств Intel I225/I226/I220/I221.

Драйверы работают для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:

Скачать Community Networking Driver for ESXi можно по этой ссылке.

Компания VMware, вскоре после большого обновления vSphere 7 Update 3, выпустила небольшой апдейт vSphere 7 U3a. С момента прошлого релиза прошло около месяца, поэтому нововведений не так много. Напомним, что в Update 3 для администраторов и DevOps появилась возможность использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

Теперь в Update 3a эта возможность позволяет вновь созданным виртуальным машинам стать частью кластера TKG (Tanzu Kubernetes Grid) с нативным исполнением команд. Это позволит:

• Компаниям использовать кластеры TKG как платформу Kubernetes с GPU-ускорением для нагрузок AI/ML.
• Администраторам получить инструмент быстрой и эффективной совместной работы над развертыванием и обслуживанием инфраструктуры контейнеров и уйти от рабочего процесса коммуникации на базе тикетов.

Инфраструктура Tanzu Kubernetes (TKr) теперь построена на Ubuntu 20.04 - сам образ был оптимизирован для использования с нагрузками AI/ML и тщательно оттестирован. Детальное руководство об использовании сервисов Tanzu для AI/ML находится в этой статье.

Также обновление содержит патч VMware vCenter Server Appliance 7.0 Update 3a, который включает в себя фиксы ошибок и исправления в подсистеме безопасности.

Скачать VMware vSphere 7 Update 3a можно по этим ссылкам:

• VMware vCenter 7 Update 3a
• VMware ESXi 7 Update 3a

Release Notes находятся тут.

Компания VMware обновила свою версию гипервизора для архитектуры ARM - версия ESXi Arm Edition 1.6 стала доступна на сайте проекта VMware Labs. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлой версии этой платформы мы писали вот тут.

Новые возможности ESXi Arm Edition 1.6:

• Экспериментальная поддержка инстансов BM.Standard.A1.160 на базе Ampere Altra в инфраструктуре Oracle Cloud
• Экспериментальная поддержка чипсетов Marvell Armada A8040 / Octeon TX2 CN9132
• Экспериментальная поддержка спецификации Socionext SynQuacer Developerbox

Напомним, что разработка версии ESXi для архитектуры ARM очень важна в рамках программно-аппаратного подхода Project Monterey, почитать об этом можно вот тут. Скачать новую версию ESXi Arm Edition 1.6 можно по этой ссылке.

Кстати, у VMware есть отдельный блог, посвященный работе ESXi на архитектуре ARM: blogs.vmware.com/arm.

Недавно компания VMware выпустила обновление VMware vSphere 7 Update 3, которое стало доступным для загрузки накануне уже прошедшей конференции VMworld Online 2021. В рамках конференции VMware рассказала о перспективах развития технологий своих серверных и десктопных продуктовых линеек, в которых ожидается много интересных нововведений в самом ближайшем будущем. Сегодня мы поговорим о трех основных анонсах...

Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:

1.Поддержка NVMe over TCP

В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.

2. Увеличение числа хостов на один датастор

У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.

3. Affinity 3.0 и поддержка CNS

В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.

4. Пакетные снапшоты томов vVols

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

Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.

Компания VMware перед предстоящей конференцией VMworld 2021 анонсировала скорую доступность для загрузки обновления своей главной серверной платформы виртуализации VMware vSphere 7 Update 3.

Нововведения будут сосредоточены в 3 основных областях:

Deliver AI and Developer-Ready Infrastructure

В новой версии vSphere была улучшена служба для развертывания виртуальных машин через стандартные Kubernetes API Virtual Machine (VM) Service, которая появилась в vSphere 7 Update 2a. Теперь администраторы и DevOps смогут использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.

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

Также было улучшено решение VMware vSphere with VMware Tanzu, которое теперь проще настраивать, особенно в части сетевого взаимодействия, на что ранее жаловались пользователи.

Создать тестовую лабораторию Kubernetes администраторам vSphere теперь стало гораздо легче.

Scale without Compromise

В этой категории улучшений больше всего изменилось в плане поддержки высокопроизводительной памяти Persistent Memory. Например, ее часто используют для таких нагрузок, как SAP HANA. Теперь в vSphere 7 Update 3 есть множество новых инструментов для анализа и настройки производительности памяти с точки зрения пропускной способности (bandwidth) и нагрузки. В дополнение к этому, теперь можно настраивать алармы на базе SLA и изменять конфигурацию машин и платформы на базе рекомендаций от механизма аналитики.

Также, поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Подробнее об этом рассказано здесь.

Simplify Operations

В новой версии vSphere 7 Update 3 появился специальный vCenter Server plug-in for NSX, который позволяет администраторам гораздо быстрее и удобнее настраивать сетевое взаимодействие и безопасность для NSX прямо из vSphere Client, без необходимости использования NSX Manager. В этой категории также появился простой процесс развертывания и настройки NSX-T, а также бесшовная аутентификация пользователей между vSphere и NSX-T.

Также механизм vSphere Distributed Resource Scheduler (DRS) теперь работает умнее в плане обработки операций обслуживания. Большие и более критичные нагрузки теперь перемещаются первыми и как можно скорее, чтобы пользователи не почувствовали никакого влияния процесса миграции во время обслуживания и апгрейда серверов.

Скачать апдейт VMware vSphere 7 Update 3, который выйдет на днях, можно будет по этой ссылке. Более подробно о новых возможностях обновления также рассказано вот в этой статье.

В начале сентября компания VMware объявила о том, что ее флагманская платформа виртуализации VMware ESXi больше не будет поддерживаться для Apple 2019 Mac Pro 7,1 в целях виртуализации Mac OS систем. Причина проста - Apple осуществляет переход на архитектуру Apple Silicon, а во времена Covid затруднено технологическое партнерство между большими компаниями в этой сфере.

Недавно мы писали, кстати, о том, что VMware работает над поддержкой продукта Fusion для Apple MacBook, но и там есть свои сложности. Новый гипервизор VMware ESXi ARM Edition еще находится на ранней стадии разработки, на его доведение до производственной версии могут уйти годы.

Поэтому на сегодняшний день VMware сворачивает сертификацию поддержку Apple 2019 Mac Pro 7,1 для ESXi, но пока оставляет ее для следующих платформ:

• Apple 2018 Mac Mini 8,1
• Apple Mac Pro 6,1

В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:

• CVE-2021-21972 - VMSA-2021-0002 (плагин vRealize Operations Manager)
• CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
• CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)

Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.

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

Чтобы отключить сразу все указанные плагины, нужно будет добавить следующий текстовый блок:

<PluginPackage id="com.vmware.vrops.install" status="incompatible"/>

<PluginPackage id="com.vmware.vsphere.client.h5vsan" status="incompatible"/>

<PluginPackage id="com.vmware.vrUi" status="incompatible"/>

<PluginPackage id="com.vmware.vum.client" status="incompatible"/>

<PluginPackage id="com.vmware.h4.vsphere.client" status="incompatible"/>

Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):

Итак, чтобы отключить плагины, вам нужно:

• Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
• Сделать резервную копию файла, например, командой:
  cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
• Открыть этот файл в текстовом редакторе командой:
  vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
• Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):

• Сохранить файл с помощью команды vi:
  :wq!
• Перезапустить сервисы vsphere-ui:
  service-control --stop vsphere-ui
service-control --start vsphere-ui

Если вы все еще используете VMware vCenter for Windows, то указанную процедуру нужно проделать в следующем файле (не забывайте сделать его бэкап):

C:\ProgramData\VMware\vCenterServer\cfg\vsphere-ui\compatibility-matrix.xml

Делается это в том же месте, что и для матрицы совместимости в vCSA:

После этого также перезапускаем службу vsphere-ui для Windows:

C:\Program Files\VMware\vCenter Server\bin> service-control --stop vsphere-ui
C:\Program Files\VMware\vCenter Server\bin> service-control --start vsphere-ui

В том, что плагины отключены вы сможете убедиться в интерфейсе vSphere Client в разделе Administration > Solutions > client-plugins:

Ну и для тех, кому удобнее воспринимать руководство в видеоформате, компания VMware сделала ролик на эту тему:

Многим Enterprise-администраторам VMware vSphere знаком сервис VMware Skyline, который позволяет проактивно получать рекомендации по технической поддержке продуктов линейки VMware vSphere, включая vSAN.

С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).

Если вы хотите спрятать некоторые советы и рекомендации, которые не требуют применения в вашей инфраструктуре, вы можете использовать специальные фильтры для вывода ненужных объектов. Например, можно спрятать Trivial Findings, которые не очень важны и только мешают увидеть серьезные проблемы.

Просто в левой панели выбираете нужный фильтр и нажимаете Hide Findings в разделе Active Findings:

Эти рекомендации не удаляются - их всегда можно увидеть на вкладке Hidden Findings (см. скриншот выше).

Далее спрятанные рекомендации можно экспортировать в CSV-файл, чтобы, например, обсудить их с командой техподдержки VMware или собственной командой:

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

Ну и чтобы посмотреть описанное в действии, можете взглянуть на это видео:

На сайте проекта VMware Labs обновилась очередная интересная утилита Storage Performance Tester, которая позволяет провести тестирование хранилищ в один клик на сервере VMware ESXi, получив метрики IOPS, latency и CPU cycles per I/O. В новой версии появилась поддержка адаптеров vnvme, а также исправления ошибок для ESXi 6.7.

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

Результаты для полученных метрик выводятся в графическом интерфейсе в виде диаграмм и комментариев к ним:

Самое приятное - это то, что утилита запускается одной командой, после чего пользователь получает итоговый результат. Выглядит это так:

#./sperf.py HOSTNAME -d DatastoreName

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

Ну и видео о том, как это все работает:

Для запуска Storage Performance Tester вам потребуется:

• Python 3
• sshpass
• 2 ГБ свободного пространства на диске
• Linux-окружение (ядро не старше 2.6.31)

Скачать Storage Performance Tester можно по этой ссылке.

Несколько дней назад на различных новостных ресурсах появилась новость о том, что хакерская группа BlackMatter (которая появилась из групп Darkside и REvil) разработала библиотеку esxi_utils, предназначенную для выполнения вредоносных операций с хост-серверами виртуализации VMware ESXi. По-сути, это Linux-шифровальщик, на базе которого строятся программы-вымогатели (Ransomware), наносящие довольно серьезный урон крупным корпорациям.

Злодеи из BlackMatter заявляют своей целью крупные компании (от $100 миллионов годовой выручки), извлеченные данные которых они планируют публиковать в открытом доступе (очевидно, только их часть), а сами данные будут зашифровывать и вымогать деньги. С точки зрения географий - это US, UK, Канада и Австралия.

Итак, на днях группировка выпустила первый Linux Encryptor (Linux ELF64), который использует интерфейс esxcli:

В сам вредоносный пакет включены компоненты, реализующие следующие методы на C:

• esxi_utils
• files_proc
• file_encrypter
• setup_impl
• web_reporter

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

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

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

Возможно, от распространения подобного рода ПО в вашей инфраструктуре вам помогут продукты VMware Carbon Black и VMware AppDefense, а возможно и нет:)

На сайте проекта VMware Labs вышло обновление ESXi Arm Edition 1.5. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлой версии этой платформы мы писали вот тут.

Кстати, есть интересное видео о продукте:

Нововведений в обновленной версии не так много:

• Небольшие улучшения производительности работы виртуальных машин
• Поддержка BCM2848 ACPI ID для порта USB OTG (затрагивает новые версии микрокода UEFI)
• Исправления небольших ошибок

Скачать новую версию VMware ESXi Arm Edition 1.5 можно по этой ссылке. Кстати, о багах и новых обсуждениях работы этой версии гипервизора можно узнавать вот тут, а здесь находится комьюнити в Slack.

Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...

Компания VMware обновила пакет драйверов Community NVMe Driver for ESXi до версии 1.1 на сайте проекта VMware Labs. Эти драйверы были выпущены в начале года, а сейчас вышло их обновление с поддержкой VMware ESXi 7.0.

Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.

Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:

Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).

Драйверы поставляются в виде VIB-пакета, установить который можно командой:

Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.

Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.

Основные темы документа:

• Что такое снапшоты
• Какие есть форматы снапшотов
• Описание тестового окружения и рабочих нагрузок
• Результаты тестирования производительности
• Выводы по этим результатам

Итак, для тестирования использовались следующие рабочие нагрузки:

• FIO (стандартный тест производительности ввода-вывода)
• JVM (бенчмарк SPECjbb 2015)
• OLTP database (тест HammerDB)

Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:

1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):

В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.

2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:

3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:

4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:

Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.

5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:

Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.

Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:

При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):

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

Итак, очевидные выводы:

• Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
• Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
• Хранилищам VVol все равно на снапшоты, производительность не падает.
• Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
• При удалении снапшотов производительность ВМ возвращается к исходному уровню.

Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).

Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
• T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
• T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
• Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин

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

• T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
• T+10 секунд – начинаются выборы нового Primary хоста в кластере
• T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
• T+35 секунд – старый хост Primary помечается как unreachable
• T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary

Надо помнить, что это все времена начала процессов, но не их завершения. Например, если процесс восстановления начинается через 15 секунд, то нужно время, чтобы найти место для виртуальной машины на новом хосте и запустить ее там – а вот это время рассчитать невозможно.

Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.

Дункан Эппинг показал на примере виртуального коммутатора vSwitch, как можно работать с configstore и хранящимися там настройками. Например, вам требуется сменить имя виртуального коммутатора. Вы можете посмотреть его текущие сетевые настройки командой:

configstorecli config current get -c esx -g network_vss -k switches

Ну а экспортировать эти настройки в JSON-файл можно командой:

configstorecli config current get -c esx -g network_vss -k switches > vswitch.json

Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:

Потом получившийся файл нужно обратно импортировать в configstore:

configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite

После этого вы увидите изменения в vSphere Client:

Также Дункан записал видео, в котором показан этот процесс:

На сайте проекта VMware Labs вышло очередное обновление - VMware ESXi Arm Edition версии 1.4. Напомним, что эта специальная версия версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О версии 1.3 мы писали в начале апреля вот тут.

Давайте посмотрим, что нового в июньской версии VMware ESXi ARM Edition 1.4:

• Улучшенная технология виртуализации PMU (Performance Monitoring Unit)
• Исправлены проблемы с виртуальным устройством AHCI для некоторых ОС ACPI
• Улучшена работа с обработкой времени
• Экспериментальная поддержка NVIDIA Tegra Xavier AGX и NVIDIA Tegra Xavier NX (PCIe, USB, NVMe, SATA). Это что-то типа вот такой штуки:

• Экспериментальная поддержка серверов 2P Ampere на базе Altra. Это вот такие штуки:

• Увеличенная производительность виртуальных машин для мультисокетных серверов на базе ARM
• Исправлены проблемы с виртуальным NVMe в UEFI для некоторых ОС
• Улучшена виртуализация контроллера прерываний
• Улучшена общая производительность гипервизора и техник виртуализации в целом
• Улучшена совместимость с ядрами Linux для новых ОС
• Исправлены проблемы стабильности USB-устройств, особенно для сетевых адаптеров на базе RTL8153 для платформ Raspberry Pi и Tegra Xavier
• Обновлена документация для ESXi-Arm Fling, Raspberry Pi, Ampere Altra, NVIDIA Xavier AGX и NVIDIA Xavier NX (опции доступны в комбобоксе при скачивании продукта)

Загрузить VMware ESXi ARM Edition 1.4 и документацию можно по этой ссылке.

На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.

Эта версия (1.8) драйверов сделана специально для VMware vSphere 7.0 Update 2. При скачивании драйверов убедитесь, что вы выбрали вариант для нужной версии ESXi:

Что нового появилось в драйверах:

• Полная поддержка ESXi 7.0 Update 2
• По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах

Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:

Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.

На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.

Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:

https://download3.vmware.com/software/vmw-tools/lib.json

Кстати, все статьи о вложенной виртуализации можно найти и у нас по тегу Nested.