На сайте проекта VMware Labs очередное обновление - новая версия утилиты vSphere Software Asset Management Tool 1.2. Напомним, что средство vSAM предназначено для сбора подробной информации об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - инвентаря и доступных лицензий. О прошлой версии vSAM мы писали вот тут (там появилась поддержка vSphere 7).

Посмотрим на новые возможности vSAM 1.2:

• Отображение в отчете информации об инфраструктуре кластеров хранилищ vSAN
• Можно открытым текстом выводить лицензионные ключи в отчете, если выставлена соответствующая опция
• В отчет добавлена таблица License Inventory

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

Если вы следите за обновлениями VMware vSphere 7, то наверняка знаете, что не так давно уже выходили минорные обновления vCenter 7.0 Update 0a и vSphere with Kubernetes.

На днях VMware выпустила еще один небольшой апдейтик - vCenter 7.0.0b (на момент написания заметки дистрибутив еще недоступен для скачивания).

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

• Новые алармы: vCenter Server 7.0.0b получил еще один аларм для vCenter Server Appliance, который срабатывает в случае, когда состояние репликации меняется на READ_ONLY. Аларм гасится, если состояние возвращается в Normal. С помощью этого аларма легко обнаружить проблемы в репликации между узлами vCenter на одной или нескольких площадках.
• C vCenter Server 7.0.0b можно использовать кнопку "Show only rollup updates", позволяющую отфильтровать и выбрать патчи, которые вы хотите включить в бейслайн для vSphere Lifecycle Manager. Кнопка доступна на вкладке Updates панели Lifecycle Manager. Также эта опция доступна в мастере создания нового бейслайна.
• Решено несколько проблем и исправлены некоторые ошибки. Посмотреть информацию о них можно тут.
• Про обновления движка VMware vSphere with Kubernetes рассказано здесь.

Скачать VMware vCenter 7.0.0b в составе vSphere 7 можно по этой ссылке.

Мы уже очень много писали о нововведениях VMware vSphere 7, но все еще есть о чем рассказывать. Не так давно мы говорили об улучшениях горячей миграции виртуальных машин vMotion в ESXi 7 (и тут), а сегодня посмотрим, как был улучшен механизм горячей миграции хранилищ Storage vMotion.

При миграциях SVMotion используется техника Fast Suspend and Resume (FSR), которая очень близка к vMotion, но не идентична ему. При горячей миграции хранилища ВМ происходит создание теневой копии этой машины на том же хосте ESXi, куда подцепляются новые хранилища или устройства, после чего происходит копирование метаданных памяти и состояния устройств от исходной ВМ к целевой. В этот момент машина "замирает" примерно на 1 секунду, а затем происходит включение уже целевой ВМ, а исходная ВМ выключается и удаляется:

Такая же методика применяется и для механизма Hot Add / Remove, который позволяет добавлять и удалять устройства виртуальной машины "на горячую" без необходимости ее выключения. Для выключенной ВМ добавление и удаление устройств - это лишь изменения в конфигурационном файле VMX.

Сам процесс FSR в целом работал довольно неплохо для небольших виртуальных машин, а прерывание работы ВМ укладывалось, как правило, в одну секунду. Но для больших машин (Monster VM) процесс копирования метеданных памяти мог занять продолжительное время.

Во время приостановки ВМ происходит копирование блоков памяти Page Frames (PFrames), представляющих собой маппинги между виртуальной памятью машины и физическими адресами Machine Page Numbers (MPN).

Эти блоки и нужно скопировать во время паузы FSR:

До VMware vSphere 7 во время копирования метаданных памяти использовался только один vCPU машины, в то время как остальные процессоры ВМ ждали окончания процесса и простаивали:

Очевидно, что для больших машин с большим объемом памяти и числом vCPU процесс работал неоптимально. В VMware vSphere 7 для копирования блоков PFrame используются все vCPU. Метаданные памяти разделяются на сегменты, и за копирование каждого сегмента отвечает свой виртуальный процессор. Сам процесс копирования происходит в параллельном режиме, что существенно экономит время на копирование:

Для обычных ВМ это улучшение вряд ли получится почувствовать на практике, но если вы используете Monster VMs, то эффект от обновленного FSR можно будет заметить. Например, VMware взяла машину с 1 ТБ памяти и 48 vCPU, которую перемещала под нагрузкой с помощью Storage vMotion. Так вот время переключения со старым FSR составило 7.7 секунды, а с новым - около 0.5 секунды для VMware vSphere 7:

Многие из вас знают, что в решении для организации отказоустойчивых кластеров хранилищ VMware vSAN есть функции дедупликации и сжатия данных (deduplication and compression, DD&C). С помощью этих функций можно более эффективно использовать ярус хранения данных виртуальных машин (Capacity Tier). О некоторых аспектах применения дедупликации и сжатия данных в vSAN мы рассказывали вот тут, а сегодня поговорим об их общем влиянии на производительность дисковой подсистемы.

Как знают администраторы vSAN, это решение использует двухъярусную архитектуру, создающую оптимальное соотношение цена/качество для хранилищ ВМ - на Cache Tier, собранном из дорогих SSD-дисков (быстро работающих на дисках), размещается Write Buffer и Read Cache, а на дешевых SSD/HDD-дисках - постоянные данные виртуальных машин.

Механизм DD&C работает так - если он включен, то как только из Cache Tier виртуальной машине отправляется квитанция о записи данных, то может начаться процесс дестейджинга данных на Capacity Tier, во время которого сам механизм и вступает в действие. Сначала с помощью механики дедупликации в рамках дисковой группы (deduplication domain) находятся идентичные блоки размером 4 КБ и дедуплицируются, а затем блоки сжимаются. При этом, если блок сжимается менее, чем на 50%, то целевое хранилище записывается оригинал блока в целях быстрого доступа при чтении (без декомпрессии).

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

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

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

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

Такая двухъярусная система vSAN имеет 2 теоретических максимума:

• Max burst rate - возможность Cache Tier сбрасывать обработанные пакеты данных в сторону Capacity Tier
• Max steady state rate - установившаяся максимальная скорость записи данных на приемнике Capacity Tier

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

Если у вас идет дестейджинг данных с включенным DD&C, это потенциально может повлиять на производительность записи данных на Capacity Tier. При использовании DD&C снижается максимальная скорость записи данных на ярус постоянного хранения, так как перед этой записью должны быть выполнены операции дедупликации и сжатия.

Иными словами, кластер с включенным DD&C может давать такие же показатели качества обслуживания, как и кластер с более медленными устройствами в Capacity Tier, но с выключенным DD&C.

Логично ожидать, что при включенном DD&C буффер Write Buffer будет заполняться скорее, так как будут возникать задержки ожидания отработки DD&C. Но пока буффер полностью не заполнен - заметных просадок в производительности не будет. Очищаться также Write Buffer будет медленнее при включенном DD&C.

Также может измениться и время отсылки квитанции о записи (acknowledgment time, оно же write latency), которое увеличит latency для виртуальной машины. Это произойдет, если уже начался дестейджинг данных, а машина запрашивает ACK и ждет ответа с уровня буффера. Хотя в целом vSAN построен таким образом, чтобы как можно быстрее такой ответ дать.

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

Если вы также используете RAID 5/6 для кластеров vSAN, то совместно с техниками DD&C могут возникнуть серьезные эффекты с влиянием на производительность. Об этих аспектах подробно рассказано вот тут - обязательно ознакомьтесь с ними (см. также комментарий к статье).

По итогу можно сделать следующие выводы из этой схемы:

• Если вам хочется использовать DD&C, и вы видите, что у ВМ высокая latency - попробуйте более быстрые диски на Capacity Tier.
• Используйте больше дисковых групп, так как Buffer и его пространство hot working set используется на уровне дисковой группы. Две группы на хосте нужно минимум, а лучше три.
• Альтернативой DD&C могут стать устройства большой емкости - там просто все поместится).
• Используйте последнюю версию vSAN - алгоритмы работы с данными все время совершенствуются.
• Также помните, что RAID 5/6 также экономит место по сравнению с RAID1, что может стать альтернативой DD&C.

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

Компания VMware недавно выпустила интересную бесплатную книгу "Micro-segmentation for Dummies Guide, 2nd Edition".

Те из вас, кто использует решение для сетевой виртуализации и агрегации трафика VMware NSX и средство обеспечения сетевой безопасности vRealize Network Insight, знают о таком подходе как микросегментация. С помощью него можно управлять сетевыми политиками на базе контекстов приложений - сетевом (на уровне 7 модели OSI), пользовательском (ID, сессия RDSH и прочее), а также рабочей нагрузки (тэги, группы безопасности).

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

Из книжки вы узнаете:

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

Скачать книгу "Micro-segmentation for Dummies Guide, 2nd Edition" можно по этой ссылке.

Часто при создании отладочного пакета vCenter Appliance log bundle на сервере VMware vCSA (он нужен для техподдержки VMware и траблшутинга) администраторы сталкиваются с недостатком свободного места в разделе /storage/log. Это бывает даже, когда у вас есть 5 ГБ свободного места - да, логи в рамках одной выгрузки могут занимать и больше!

Чтобы найти прошлые логи и удалить их с сервера vCSA, нужно зайти на него по SSH и перейти в категорию /storage/log. Далее найти логи можно командой:

find . -iname *.tgz

В соответствующих папках будут лежать эти файлы журналов. Удалить их можно стандартной командой:

rm *.tgz

После этого нужно перезапустить управляющие службы vCSA:

service-control --stop --all
service-control --start --all

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

На сайте проекта VMware Labs обновилась полезная утилита VMware App Volumes Entitlement Sync до версии 4.0. Напомним, что она позволяет прочитать, сравнить и синхронизировать права доступа к объектам между экземплярами App Volumes на географически разделенных площадках. После аутентификации на обеих площадках вы сможете выбрать права доступа, которые надо сравнить или синхронизировать. О прошлой версии Entitlement Sync 2.3 мы писали вот тут.

Давайте посмотрим на возможности обновленного App Volumes Entitlement Sync 4:

• Добавлена поддержка App Volumes 4.x - как для Application Packages, так и старых Legacy 2.x AppStacks
• Все еще поддерживаются App Volumes Managers версии 2.x
• Исправления ошибок в связке Application / Package при репликации
• Сохранение адреса сервера, имени пользователя и домена в реестре
• Улучшенный механизм логгирования и обработки ошибок
• Возможность с инхронизировать объекты Application Package Markers
• Можно удалять пустые приложения
• Определение и отображения выбранного типа назначения (assignment type)
• Отображение версии текущего маркера (либо показывается, что его нет)
• Отображение версии App Volumes Manager на главной странице

На портале VMware Learning появились новые лабы (они же Hands-on Labs), которые посвящены новой версии платформы VMware vSphere 7:

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

На данный момент доступны следующие лабы:

• HOL-2111-01-SDC – VMware vSphere – What’s New
• HOL-2111-02-SDC – VMware vSphere – Advanced Topics
• HOL-2111-03-SDC – VMware vSphere – Security Getting Started

В этих лабораторных работах содержится около трех часов контента, с помощью которого вы сможете узнать обо всех нововведениях vSphere 7 в деталях. Скоро также обещают и лабы по vSphere 7 with Kubernetes, что будет очень полезно, так как многие пользователи не могут попробовать контейнеризованные приложения в своей виртуальной инфраструктуре.

Также уже довольно давно доступна лаба VMware Cloud Foundation 4 Hands-on Lab - напомним, что архитектура VCF 4 также построена на базе VMware vSphere 7.

Мы много писали о возможностях новой версии платформы 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 с таких устройств, если они были созданы установщиком по умолчанию.

Осенью 2018 года мы писали об утилите True SSO Diagnostic Utility, с помощью которой можно проводить диагностику сертификатов Horizon View Enrollment Server (ES), настроек Active Directory PKI и свойств служб сертификации Enterprise Certificate Authorities (CA).

На днях же VMware на сайте Labs выпустила еще одно средство - True SSO Configuration Utility, предназначенное уже не только для диагностики, но и настройки сертификатов True SSO для использования с View Connection Server, Enrollment Server и вашим центром сертификации (Certificate Authoriry) и Active Directory.

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

• VMware Horizon Connection Server
• VMware Horizon Enrollment Server
• Microsoft Certificate Authority
• Workspace One Access

Чтобы начать использовать True SSO Configuration Utility нужно лишь запустить ее на Horizon Connection Server.

Видео установки и первоначальной настройки можно скачать по этой ссылке, а само средство True SSO Configuration Utility доступно для загрузки здесь.

На сайте проекта VMware Labs появилась очередная полезность - утилита Workspace ONE App Analyzer for macOS, с помощью которой можно детектировать необходимые для устанавливаемого приложения разрешения (Privacy Permissions), расширения ядра (Kernel Extensions) и системные расширения (System Extensions).

Это потом можно использовать для автоматического создания профилей в Workspace ONE UEM, чтобы там добавить в whitelist требуемые настройки для приложений.

Для работы утилиты потребуется MacOS 10.15 или более поздней версии. Утилита была протестирована с Workspace ONE UEM 2004. Скачать Workspace ONE App Analyzer for macOS можно по этой ссылке (на вкладке Instructions есть небольшое описание рабочего процесса).

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

Начал он с того, что в переменную $server2012 он записал количество гостевых операционных систем определенного типа с помощью команды:

$server2012 = ((get-vm).extensiondata.guest | Where GuestFullName -eq "Microsoft Windows Server 2012 (64-bit)").count

Далее он стал думать, как сделать таблицу со всеми ОС, для этого решил создать хэш-таблицу, куда будут записываться типы гостевых ОС и их количество:

$OS_hashtable = $null

$OS_hashtable = @{}

$VMs = Get-VM

foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

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

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

# Added this to the beginning of the script

  $NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt

# Added this to the foreach loop section

  IF ($OSName -eq $NullOS){$OSName = "Unknown"}

Итоговый скрипт получился таким:

$debug = $false
$OS_hashtable = $null
$OS_hashtable = @{}
$NullOS = Get-Content C:\Scripts\Logs\Guestfullname.txt
$VMs = Get-VM
Foreach ($VM in $VMs){
    $OSName = $VM.ExtensionData.Guest.GuestFullName
    IF ($OSName -eq $NULL){$OSName = $VM.ExtensionData.Config.GuestFullName}
    IF ($OSName -eq $NullOS){$OSName = "Unknown"}
    IF ($debug){write-host "$VM - $OSName"}
    If(!($OS_hashtable.ContainsKey($OSName))){
        $OS_hashtable.add($OSName,0)
    }
    $Value = $OS_hashtable.$OSName
    $NewValue = $Value + 1
    $OS_hashtable[$osName] = $NewValue
}
$OS_hashtable | FT -AutoSize

Для тех, кому хочется послушать о самых актуальных новостях Veeam этого года на русском языке, пройдет бесплатная онлайн-конференция VeeamON Tour 2020. Команда системных инженеров готовит шесть технических сессий в прямом эфире на выбор. Позже Veeam отправит их запись всем участникам.

Дата проведения: 25 июня 2020 года с 11:00 до 13:15 мск.

Темы сессий:

• Реализация Veeam NAS Backup в версии 10
• Практические рекомендации по защите данных от программ вымогателей
• Рекомендации по планированию инфраструктуры Veeam Backup & Replication v10
• Лучшие практики и рекомендации для успешной работы с Veeam Agents
• Все об интеграции с СХД и новые возможности Veeam v10
• Защита данных облачного Microsoft Office 365

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

Участие бесплатное, требуется регистрация. Зарегистрируйтесь по этой ссылке.

Компания VMware выпустила на днях обновление одного из самых главных своих документов - "Performance Best Practices for VMware vSphere 7.0". Мы не зря в заголовке назвали это книгой, так как данный документ представляет собой всеобъемлющее руководство, где рассматриваются все аспекты поддержания и повышения производительности новой версии платформы VMware vSphere 7.0 и виртуальных машин в контексте ее основных возможностей.

На 96 листах очень подробно описаны лучшие практики для администраторов платформы и гостевых ОС:

Вот все корневые разделы этого руководства:

• Persistent memory (PMem), including using PMem with NUMA and vNUMA
• Getting the best performance from NVMe and NVME-oF storage
• AMD EPYC processor NUMA settings
• Distributed Resource Scheduler (DRS) 2.0
• Automatic space reclamation (UNMAP)
• Host-Wide performance tuning (aka, “dense mode”)
• Power management settings
• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance from iSCSI and NFS storage
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Running network latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Microsoft Virtualization-Based Security (VBS)
• Selecting virtual network adapters
• vCenter database considerations
• The vSphere HTML5 Client
• VMware vSphere Lifecycle Manager
• VMware vSAN performance

Для администраторов больших инфраструктур, активно внедряющих новые технологии (например, хранилища с Persistent Memory или DRS 2.0), появилось много всего нового и интересного, поэтому с книжкой нужно хотя бы ознакомиться по диагонали, останавливаясь на новых функциях ESXi 7 и vCenter 7.

Скачать PDF-версию "Performance Best Practices for VMware vSphere 7.0" можно по этой ссылке.

Компания VMware объявила о том что продляет поддержку (General Support) для платформы VMware vSphere версии 6.7 до 15 октября 2022 года. Напомним, что ранее эта поддержка была заявлена до 15 ноября 2021 года. Таким образом, срок действия поддержки General Support был продлен на 11 месяцев.

General Support Phase - эта фаза начинается после выпуска мажорного релиза (GA) и длится довольно долгое время. В этот период пользователи, купившие официальную поддержку VMware (а не купить ее нельзя), получают апдейты и апгрейды, багофиксы и исправления безопасности, а также техническое сопровождение в соответствии с Terms and Conditions.

Дата наступления EoTG (End of Technical Guidance) останется неизменной - это 15 ноября 2023 года. В рамках этой фазы, которая начинается с момента окончания General Support, предоставляются инструкции через портал самообслуживания, а по телефону звонки уже не принимаются. В этой фазе можно открыть кейс в техподдержке онлайн, но только для поддерживаемых конфигураций. В этой фазе VMware не оказывает поддержки, касающейся оборудования, обновлений ОС, патчей безопасности или багофиксов (если о другом не объявлено дополнительно). Предполагается, что в этой фазе пользователи используют стабильные версии ПО и конфигураций при нормальных (не повышенных) нагрузках.

Более подробно о сроках поддержки и Technical Guidance для продуктов VMware можно прочитать в документе "VMware Lifecycle Product Matrix".

На днях компания VMware объявила о выпуске обновленного решения VMware Cloud Director Availability 4.0, которая предназначена для создания резервной инфраструктуры в одном из публичных облаков сервис-провайдеров на основе VMware vCloud Director (так называемая услуга Disaster-Recovery-as-a-Service, DRaaS).

Предыдущая версия VMware vCloud Availability 3.5 вышла в конце прошлого года, давайте посмотрим, что теперь нового в VMware Cloud Director Availability 4.0 (обратите внимание на изменение названия). Daniel Paluszek написал отличный обзор новой версии VCDA 4.0, выдержки из которого мы и приведем ниже.

Новые возможности и улучшения сосредоточены в трех областях:

Блок Service Operation

В плане данных функций здесь появилось множество новых возможностей, таких как:

• Визуализация используемых ресурсов (CPU, память, сеть и диск) как для провайдера, так и для клиентов облака. Для провайдера это выглядит так:

Для клиентов так:

• Open API для отслеживания использования трафика и потребления дисковых ресурсов на базе организации или клиента:

Провайдер может также экспортировать статистики на нужном уровне гранулярности. Подробнее можно узнать об этом на VMware Code.

• Возможность экспорта логов VCDA 4.0 в любой syslog collector (например, vRealize Log Insight). Настройки отправки событий можно кастомизировать:

Блок Service Operation

• Функция SLA Profiles - это наборы настроек, которые обеспечивают заданный уровень обслуживания защищаемых виртуальных машин (например, требования к контрольной точке восстановления RPO на приемнике):

• Stored Instances - это хранимые во времени состояния виртуальных машин, которые можно оставлять на хранилище согласно политикам, а можно сохранить отдельные инстансы в нужной точке:

• Горячее изменение размера дисков - начиная с vSphere 7, можно изменять размер дисков ВМ без разрушения рабочего процесса репликации.

Блок Platform Integration

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

• Интеграция c VMware Cloud Director (VCD). Теперь операции VCD 10.1 и VCDA 4.0 интегрированы напрямую через меню действий:

Скачать VMware Cloud Director Availability 4.0 можно по этой ссылке.

На сайте проекта VMware Labs появилась еще пара интересных обновлений.

Первое - новая версия FlowGate 1.1. Эта утилита представляет собой средство для агрегации данных из различных источников. Это middleware, которое позволяет провести агрегацию данных систем инвентаризации датацентров DCIM / CMDB и далее передать их в системы управления задачами инфраструктуры (например, vRealize Operations). Напомним, что о прошлой версии этого средства мы писали вот тут.

Что нового в обновлении FlowGate 1.1:

• Переработаны адаптеры powerIQ и Nlyte - теперь они поддерживают больше метрик и свойств
• Доработан Metric API
• Улучшена функциональность ручного маппинга, включая поддержку PDU, коммутаторов и сенсоров
• Добавлена поддержка маппинга IP и AssetName
• Исправлены проблемы безопасности
• Существенно уменьшен размер инсталляции

Скачать FlowGate 1.1 можно по этой ссылке.

Второе - обновилось решение VMware OS Optimization Tool до версии b1160 от 2 июня 2020 года. Напомним, что о прошлой его версии мы писали вот тут.

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

Давайте посмотрим, что нового появилось в июньском апдейте OS Optimization Tool:

• Windows Update - новая опция, которая называется Update, позволяющая заново включить функционал Windows Update, который был ранее отключен в рамках оптимизации
• Полностью переработанный интерфейс, позволяющий проще изменять настройки и кастомизировать файл ответов
• Добавлены команды, с помощью которых можно отключить службы App Volumes, если они установлены, перед запуском шагов стадии Finalize
• Выбор опций стадии Finalize теперь сохраняется между прогонами утилиты, что позволяет не терять время на выставление настроек заново
• Стандартизация опций командной строки (теперь можно использовать -optimize или -o и т.п.)
• Удалены оптимизации, которые будучи не выбраны по умолчанию, могли приводить к проблемам. Например, Disable Scheduled Tasks и CacheTask
• Обновлено руководство VMware Operating System Optimization Tool Guide
  

Скачать VMware OS Optimization Tool b1160 можно по этой ссылке.

На днях компания Microsoft запустила превью-версию своего нового облачного предложения - Azure VMware Solution, которое позволяет исполнять нагрузки vSphere нативно и прямо из облака, что упрощает миграцию существующих клиентов VMware, которые имеют онпремизные инсталляции.

Решение Azure VMware Solution включает в себя не только саму платформу виртуализации vSphere, но и продукты VMware NSX-T для сетевой виртуализации, HCX для пакетной и бесшовной миграции виртуальных машин в публичное облако, а также VMware vSAN для обеспечения отказоустойчивости виртуальных хранилищ.

Очевидно, что Microsoft пытается этим предложением привлечь тех клиентов, которые зависят от инфраструктуры Windows и других решений MS, таких как SQL Server. VMware тоже не остается в накладе - ведь лицензионные отчисления она получает от потребленных клиентами Azure ресурсов.

Пользователи Azure VMware смогут выполнять стандартные операции с виртуальной инфраструктурой, такие как создание виртуальных машин, путем стандартных инструментов - графической консоли, API-вызовов и утилит командной строки. Для всего этого будет работать инфраструктура Single Sign-On (SSO). На платформе VMware вы также сможете использовать все привычные инструменты, такие как vSphere Client.

Более подробно о решении Azure VMware Solution можно почитать на этой странице. Со стороны VMware информация доступна тут.

В конце января этого года мы писали о технологических превью новых версий настольных платформ виртуализации VMware Workstation 2020 H1 и Fusion 2020 H1. Пока над их финальными релизами все еще идет работа, компания VMware выпустила промежуточные обновления Workstation 15.5.5 и Fusion 11.5.5. Напомним, что о версиях WS 15.5 и Fusion 11.5 мы писали вот тут.

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

Что нового в VMware Workstation 15.5.5:

• Поддержка Windows 10 и VBS: VMware Workstation 15.5.5 теперь может работать на платформе Windows со включенными функциями Hyper-V (например, virtualization based security - VBS). В этом случае нужно соблюсти следующие требования:
  • CPU - Intel Sandy Bridge или новее, AMD Bulldozer или новее
  • Поддерживаемые ОС - Windows 10 20H1 build 19041.264 или новее
• Поддержка гостевых ОС:
  • Windows 10 20H1
  • Ubuntu 20.04
  • Fedora 32
• Поддержка новых хостовых ОС:
  • Windows 10 20H1
  • Ubuntu 20.04
• Улучшения производительности, подсистемы безопасности, а также множество исправлений ошибок

Скачать VMware Workstation 15.5.5 можно по этой ссылке. Release Notes доступны тут.

Что нового в VMware Fusion 11.5.5:

• Поддержка контейнеризованных приложений: операции pull, push, build для образов и запуск контейнеров командой vctl
• Поддержка гостевых ОС:
  • Windows 10 20H1
  • Ubuntu 20.04
  • Fedora 32
• Улучшения производительности, подсистемы безопасности, а также множество исправлений ошибок

Скачать VMware Fusion 11.5.5 можно по этой ссылке. Release Notes доступны тут.

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

Продукт продолжает развиваться, ведется большая работа над улучшением производительности и ошибками, давайте посмотрим, что в нем появилось интересного для платформ vSphere и Hyper-V:

• Для виртуального модуля StarWind VSAN for vSphere OVF (версия 20200515) была обновлена версия ядра Linux.
• Функция полной синхронизации с проверкой контрольных сумм (CRC), добавленная в прошлом релизе, теперь используется только для хранилищ на базе MS Storage Spaces. В этом случае тип синхронизации (Full или Full hash) показан в Management Console.
• Для старых хранилищ используется старый алгоритм с копированием данных без дополнительной проверки CRC, чтобы не влиять на производительность.
• Для запроса CRC исправлена проблема с Memory alignment. Также была исправлена проблема совместимости для виртуального модуля StarWind VSA.
• Множество исправлений ошибок, в том чиле важных с возможным повреждением данных - поэтому обязательно нужно обновиться.

• Добавлена проверка размера сектора для образа Flat Image - нельзя создать Flat Device с размером сектора 512 бай при физическом размере 4096 байт.
• Добавлен параметр валидации формата (format) для вызова Add-RamDevice. Допустимые значения: fat16, fat32, ntfs, raw.
• Добавлен параметр "force" для команды "remove".
• Добавлено свойство CreateTapeOnExport для вызова VTL ApplyReplicationSettings(). Подробнее в сэмпле скрипта VTLReplicationSettings.ps1.

• Запись нотификаций в текстовый файл не всегда теперь держит его открытым, а открывает и закрывает при необходимости.
• Улучшена безопасность при работе с SMTP и пофикшен баг с отсылкой письма без аутентификации.

• Число файлов в Log Rotate было увеличено до 20 во время обновлений существующих установок.

• Пофикшена ошибка с отображением событий из Event Log в зоне нотификаций. Иногда эти события не отображались.

Хранилища Flat Storage

• Улучшена обработка ответов для команд UNMAP/TRIM от хранилищ с файловой системой ReFS.

Прочее

• Исправления для процессинга команды EXTENDED COPY(LID4), которая возвращала ошибки в прошлых версиях.

Скачать самый свежий релиз StarWind Virtual SAN V8 for Hyper-V от 6 мая 2020 (build 13586) года можно по этой ссылке, а StarWind VSAN for vSphere OVF (версия 20200515 от 18 мая) - по этой ссылке.

Как знает большинство администраторов VMware vSphere, у данной платформы есть очень удобная сущность Content Library, которая позволяет хранить контент различного типа (скрипты, ISO-образы, текстовые файлы), в том числе шаблоны виртуальных машин. В обновленном решении VMware vSphere 7 появилось несколько новых возможностей по работе с библиотеками, о которых мы рассказывали вкратце, а сегодня поговорим подробнее.

Первое важное нововведение - представление для управления шаблонами, в котором доступны функции Check-In и Check-Out для работы с версиями шаблонов и возможностью откатиться к предыдущей версии.

Ранее при работе с шаблонами в формате VM Template (*.vmtx) администратор vSphere должен был выполнить следующую последовательность действий:

• Конвертировать шаблон в виртуальную машину
• Сделать снапшот ВМ на случай того, что что-то пойдет не так
• Обновить гостевую ОС или другие настройки ВМ
• Конвертировать ВМ назад в шаблон
• Скопировать шаблон обратно в Content Library
• Удалить старый шаблон из библиотеки

Теперь это все выглядит гораздо проще. Для внесения изменений в шаблон нужно сделать просто Check-Out его из библиотеки:

Этот процесс вовлекает последовательность действий, но даже во время нее можно развертывать новые ВМ из этого шаблона (просто остальные пользователи не могут сделать Check-Out).

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

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

Версионирование позволяет откатиться к любой версии шаблона, а также удалить ее из цепочки:

Кроме того, теперь у Content Library появились расширенные настройки (Advanced Configuration), доступ к которым можно получить вот тут:

Сами настройки выглядят так (можно выбрать один из серверов vCenter, где изменяются настройки):

Обратите внимание, что для применения некоторых настроек нужно будет перезагрузить сервис Content Library. Делается это из интерфейса vCenter Appliance Management Interface (VAMI). Для этого вас перенаправят на страницу https://<vCenterServer-FQDN>:5480:

Также в vSphere 7 был улучшен механизм привилегий для библиотек контента:

Ну и напоследок отметим, что еще в PowerCLI 11.5 появилось несколько новых командлетов для управления библиотеками контента. В PowerCLI 12 все еще лучше.

На сайте проекта VMware Labs появилось обновление очередной полезной администраторам VMware Horizon утилиты - Horizon Session Recording 2.0.8. О прошлой версии этого средства мы писали вот тут.

Данная утилита предназначена для записи пользовательских сессий и активности в виртуальных десктопах и приложениях, доставляемых по протоколу Blast Extreme. С помощью Session Recording администратор Horizon имеет возможность перенаправить запись экрана сессий пользователей, сделанных в определенное время, на центральный сервер, где потом он может воспроизвести их в HTML5-консоли. Саму сессию в виде видеофайла можно скачать как MP4 для воспроизведения в локальном плеере.

В обновленной версии Horizon Session Recording появились следующие новые возможности:

• Агент теперь реализован в несколько потоков, что увеличивает быстродейтсвие
• Веб-сервис переписан на фреймворке Angular
• Веб-сервис поддерживает функции высокой доступности (читайте в документации)
• Поддержка Horizon 7.9 и поздних версий (более ранние не поддерживаются)

Скачать Horizon Session Recording 2.0.8 можно по этой ссылке. Документация доступна там же при выборе PDF-файла из комбобокса.

Мы много писали о новых возможностях платформы VMware vSphere 7, но невозможно рассказать обо всех ее нововведениях в одной статье. Сегодня мы расскажем об одной интересной штуке - компоненте Watchdog Timer, который мы упоминали в одном предложении в статье о новых фичах.

Теперь для виртуальных машин доступно специальное устройство virtual watchdog timer (vWDT), которое позволяет администраторам в унифицированном виде узнавать о том, что гостевая операционная система и приложения данной ВМ зависли или вывалились в синий экран. Это особенно важно для кластеризованных приложений в целях поддержания их доступности.

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

Это виртуальное устройство пробрасывается в гостевую ОС через механизм BIOS/EFI ACPI и настраивается на уровне гостевой системы или самого BIOS/EFI.

Таблица Watchdog Resource Table (WDRT) имеет несколько регистров, в которые можно записать значения таймера, действия по их истечению и другие параметры. Большинство современных ОС поддерживают интеграцию с таблицей Watchdog Action Table (WDAT), определяющей список доступных действий для таймеров, которые и использует компонент WDRT.

Вот список доступных инструкций WDAT:

• WATCHDOG_ACTION_RESET
• WATCHDOG_ACTION_QUERY_CURRENT_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_SET_COUNTDOWN_PERIOD
• WATCHDOG_ACTION_QUERY_RUNNING_STATE
• WATCHDOG_ACTION_SET_RUNNING_STATE
• WATCHDOG_ACTION_QUERY_STOPPED_STATE
• WATCHDOG_ACTION_SET_STOPPED_STATE
• WATCHDOG_ACTION_QUERY_REBOOT
• WATCHDOG_ACTION_SET_REBOOT
• WATCHDOG_ACTION_QUERY_SHUTDOWN
• WATCHDOG_ACTION_SET_SHUTDOWN
• WATCHDOG_ACTION_QUERY_WATCHDOG_STATUS
• WATCHDOG_ACTION_SET_WATCHDOG_STATUS

Для большинства современных серверных ОС Windows и Linux не требуется каких-либо действий для дополнительной настройки таймера, но они могут понадобиться для некоторых старых систем, а FreeBSD или Mac OS X вовсе не поддерживают Watchdog Timer. Вот в целом информация о его поддержке:

• Windows 2003 поддерживает Watchdog Resource Table (WDRT)
• Windows 2008 и более поздняя поддерживает Watchdog Action Table (WDAT). Гостевая ОС не требует дополнительной конфигурации.
• Linux-дистрибутивы, такие как Ubuntu 18.04 и Red Hat Enterprise Linux 7.6, на базе ядра 4.9 или более позднего поддерживают Watchdog Action Table (WDAT). Для этого нужен драйвер wdat_wdt.ko.

Для настройки вам понадобится виртуальная машина с VM hardware версии 17 (появилось в vSphere 7). Надо просто добавить устройство Watchdog Timer:

Как вы видите, виртуальный Watchdog Timer можно включить либо на уровне BIOS/EFI (тогда он будет запускаться до старта ОС), либо на уровне гостевой ОС. Помните, что если гостевая ОС не поддерживает это устройство, то машина будет постоянно перезапускаться по команде от устройства Watchdog.

В vSphere Client видна информация о статусе исполнения Watchdog Timer. Не запущен:

Запущен:

Не так давно мы писали о новом релизе архитектуры VMware Cloud Foundation 4.0, которая представляет собой комплексное программное решение, включающее в себя компоненты VMware vRealize Suite, VMware vSphere Integrated Containers, VMware Integrated OpenStack, VMware Horizon, NSX и другие, работающие в онпремизной, облачной или гибридной инфраструктуре предприятия под управлением SDDC Manager.

В рамках новой версии VCF 4.0 была анонсирована поддержка архитектуры контейнеров приложений в виртуальных средах VMware vSphere with Kubernetes (ее эволюцией является нативная платформа Project Pacific). С этого момента, чтобы обеспечить поддержку контейнеров, пользователям VCF приходилось иметь минимум 7 серверов - 4 сервера для домена управления VCF Management Domain и 3 сервера для Virtual Infrastructure (VI) Domain.

Теперь домен VI можно размещать в рамках домена VCF Management, что сокращает число минимально необходимых хостов до четырех:

Таким образом, теперь VCF поддерживает 2 архитектуры:

• Consolidated architecture - один кластер vSphere развертывается как часть Management Domain. Пулы ресурсов позволяют изолировать управляющие нагрузки (экземпляры vCenter, NSX Manager, SDDC Manager и т.п.) от нагрузок виртуальных машин. В этом случае нужно минимум 4 хоста для управляющего домена.
• Standard architecture - управляющие нагрузки и виртуальные машины исполняются на разных хостах в разных доменах рабочей нагрузки. ВМ развертываются в отдельных кластерах vSphere, которые работают в рамках доменов Virtual Infrastructure (VI) domains. Это позволяет не только отделить среды на физическом уровне, но и разнести их по разным окружениям разных экземпляров vCenter. Такая архитектура считается рекомендуемой. В рамках окружения VCF можно развернуть до 14 доменов VI и один Management Domain, каждый домен может иметь несколько кластеров в vSphere (в каждом кластере минимум 3 хоста).

Более подробно об этой поддержке написано в документе "VMware vSphere with Kubernetes support on the VMware Cloud Foundation Management Domain".

На днях компании Dell EMC и VMware (которые как бы одна компания) анонсировали второе поколение программно-аппаратных комплексов VMware Cloud on Dell EMC 2nd Generation. Напомним, что о первом поколении этого решения, анонсированного на VMworld 2019, мы писали вот тут.

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

Теперь к стойке R1 (24 юнита) добавлена еще и полноразмерная стойка R2 на 42 юнита, которая включает в себя зарезервированные коммутаторы, умные розетки PDU и устройства для удаленного управления SD-WAN. В стойку поместится до 16 рабочих узлов (instance nodes):

В стойке R2 нет UPS, так как подразумевается, что сервисы бесперебойного питания предоставляются на уровне датацентра.

Также существенно изменились и спецификации узлов, которых теперь три типа:

Хосты VxRail теперь сделаны на базе второго поколения процессоров Intel SP, предоставляющих до 48 ядер на 2 физических сокета. По памяти максимум - это 768 GB RAM и 23 TB хранилища NVMe all-flash. Все это хорошо подходит под задачи тяжелых баз данных, приложений AI/ML и высоконагруженных виртуальных ПК.

Для резервного копирования сертифицированы 2 решения:

• Dell EMC PowerProtect Cyber Recovery
• Veeam Availability Suite

Также в рамках архитектуры экспериментально поддерживается решение VMware HCX, чтобы создать единую среду между онпремизным датацентром и облачным на основе архитектуры VMware Cloud Foundation (VCF), где работают средства по обеспечению катастрофоустойчивости рабочих нагрузок VMware Site Recovery Manager. С помощью HCX можно смигрировать сотни рабочих нагрузок одновременно из локального датацентра в облачный.

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

Ранее VMware Cloud Console предоставляла возможности управления гибридной инфраструктурой только для VMware Cloud on AWS SDDC, теперь же это поддерживается и для датацентров VMware Cloud on Dell EMC SDDC:

Больше информации о решении VMware Cloud on Dell EMC можно получить на основной странице продукта.

Для платформы VMware vSphere 7 вышло первое обновление - стал доступен для скачивания апдейт управляющего сервера VMware vCenter 7.0 Update 0a.

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

Она заключалась в том, что vSphere Lifecycle Manager и службы vSAN File Services не могли быть одновременно включены в кластере. Если вы включали что-то из этого первым, то второй компонент не мог быть включен после этого (они не были совместимы между собой). Теперь это поправили - и они вполне работают вместе.

Скачать VMware vCenter 7.0 Update 0a можно по этой ссылке.

Помимо этого, были обновлены и службы VMware vSphere with Kubernetes, включающие в себя виртуальный модуль Tanzu Kubernetes clusters OVA. Из нового там появилось:

• Службы Tanzu Kubernetes Grid Service for vSphere:
  • Пользователи могут накатывать последовательные обновления rolling upgrades на узлы worker nodes и control plane nodes для Kubernetes Grid Service for vSphere и апгрейдить службы pvCSI, Calico и authsvc. Также для этих компонентов предусмотрены процедуры пре-чеков перед апгрейдом.
  • Последовательные обновления rolling upgrades могут быть использованы для одновременного с апгрейдом изменения класса ваших узлов на больший или меньший по размеру.
• Для Supervisor cluster поддерживаются новые версии Kubernetes с возможностью апгрейда:
  • Kubernetes 1.17.4
  • С версии Kubernetes 1.16.x можно обновиться на 1.17.x

На сайте проекта VMware Labs появилась еще одна узкоспециализированная, но интересная штука - проект Supernova. С помощью данного интерфейса разработчики решений, использующих машинное обучение (Machine Learning), могут создавать свои проекты на базе различных открытых библиотек с поддержкой технологий аппаратного ускорения графики.

Типа таких:

Проект Supernova поддерживает все самые популярные технологии аппаратного ускорения 3D-графики:

• Nvidia GPU
• Intel IPU/VPU
• Intel FPGA
• Google (Edge) TPU
• Xilinx FGPA, AMD GPU

Для работы Supernova поддерживается ОС Ubuntu или CentOS с контейнерным движком Docker. Сфера применения решения очень широка - распознавание лиц (пол, возраст, эмоции), номерных знаков автомобилей, задача классификации объектов и многое другое.

В качестве тулкитов совместно с Supernova можно использовать следующие:

• OpenVINO
• SynapseAI
• TensorRT
• Tensorflow Lite
• Vitis
• RoCm

Данные для тренировки нейронных сетей могут быть представлены в форматах Tensorflow, Caffe, ONNX и MxNet. Примеры работы с ними представлены в документации, которую можно скачать вместе с пакетом.

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

Оказывается, на ресурсе VMware Techzone есть не только образовательные материалы, но и полезные утилиты, в частности, VMware Digital Workspace Topology Design Tool. С помощью этого средства администратор может выбрать имеющиеся у него компоненты решений VMware Workspace ONE и VMware Horizon, а также указать вариант развертывания - и нарисовать архитектурную диаграмму сетевой инфраструктуры.

Чтобы получить доступ к этой утилите, переходим по данной ссылке и в разделе Architect and Integrate кликаем по ссылке Launch для виджета Digital Workspace Topology Tool:

После этого нас попросят авторизоваться с кредами My VMware или Partner Portal и попросят ввести название профиля:

Далее нужно выбрать компоненты инфраструктуры Workspace ONE, которые будут использоваться для построения архитектуры (то есть те, которые вы планируете развертывать):

Дальше нужно указать уже компоненты инфраструктуры Horizon, для варианта On-Premises нужно выбрать составляющие решения Horizon 7 в инфраструктуре на вашей площадке:

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

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

Также можно и сохранить полученную конфигурацию в своем профиле (иконка с дискетой).

Как все уже знают, в новой версии платформы виртуализации VMware vSphere 7 средство обновления виртуальной инфраструктуры VMware Update Manager (VUM) уступило место новому продукту - VMware Lifecycle Manager.

Ранее администраторы vSphere использовали VUM для обновлений серверов ESXi и драйверов, а утилиты от производителей серверов - для обновления их микрокода (firmware). Теперь эти процессы объединяются в единый механизм под управлением vSphere Lifecycle Manager.

На сайте buildvirtual.net появился обзор процесса апгрейда хост-серверов ESXi на версию 7.0, который мы приводим ниже, чтобы дать понимание того, что сам процесс, в плане накатывания апгрейда, от VUM почти ничем не отличается.

Итак, сначала надо импортировать ISO-образ в Lifecycle Manager. Запускаем его в vSphere Client и переходим в раздел Imported ISOs:

Нажимаем Import ISO и указываем ISO-образ ESXi 7.0, который скачали с сайта VMware:

После этого данный образ появится в списке:

Затем надо создать бейслайн с этим образом. Нажимаем ссылку New Baseline, где далее указываем тип содержимого Upgrade:

Выбираем образ, который мы хотим привязать к бейслайну:

После этого созданный бейслайн нужно привязать к хостам или кластеру. Для этого выбираем пункт Attach Baseline or Baseline Group:

После успешной привязки к кластеру, жмем кнопку Check Compliance, которая запускает проверку соответствия хостов заданному бейслайну. В итоге мы увидим, например, что 4 хоста находятся в статусе non-compliant, то есть им можно накатить апгрейд (в данном случае - с версии 6.7 на 7.0):

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

Если ничего критичного не нашлось, жмем на кнопку Remediate:

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

В консоли вы увидите, что ESXi 7.0 установлен:

То же самое будет и в vSphere Client:

Как видно из описаний шагов, процесс апгрейда с помощью Lifecycle Manager практически ничем не отличается от оного с помощью Update Manager.

Вильям Лам написал интересную заметку о том, как пробросить USB-клавиатуру или мышь хоста ESXi (они называются USB HID Devices) в гостевую ОС виртуальной машины на VMware vSphere.

Такое может понадобиться, например, когда требуется пробросить в конкретную ВМ отдельную пару USB-устройств ввода (клавиатура+мышь), помимо выделенного устройства vGPU. Также некоторые другие устройства (например, датчики температуры) также притворяются HID-девайсами. Хост ESXi в этом случае по умолчанию не считает необходимым подцеплять такие устройства никуда.

Это поведение можно изменить, добавив следующие параметры в VMX-файл виртуальной машины (или ее Advanced Settings):

usb.generic.allowHID = "TRUE"
usb.quirks.device0 = "X:Y allow"

Вторая вещь, которая вам может понадобиться - это проброс USB-устройств Chip Card Interface Devices (CCID) в виртуальную машину (например, ридер смарт-карт). Для этого в VMX нужно добавить следующие строчки:

usb.generic.allowCCID = "TRUE"
usb.quirks.device0 = "X:Y allow"

В обоих этих случаях X - это vendorId, а Y - deviceId (например, выглядит так - 0x03f0:0x0024).

Чтобы узнать эти параметры, нужно выполнить в консоли ESXi команду lsusb.

После добавления указанных настроек виртуальная машина должна увидеть эти USB-устройства с хоста.