Компания 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 Labs очередная новая штука - vSphere Alert Center. Администраторы VMware vSphere часто настраивают алармы в vSphere Client, которые срабатывают при превышении некоторых критических порогов в виртуальной инфраструктуре. Эти алармы можно посмотреть в клиенте, но для них нельзя сделать прямые пуш-нотификации для администратора.

vSphere Alert Center работает в Windows, macOS и Linux (есть три отдельных дистрибутива). С помощью таких технологий, как Angular, Electron и vSphere.js компания VMware сделала утилиту, которая может соединяться с несколькими инстансами vCenter одновременно и показывать детальную информацию обо всех алармах.

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

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

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

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

Глобальные разделы документа:

• Hardware for Use with VMware vSphere - о том, какое оборудование и как работает с платформой
• ESXi and Virtual Machines - об оптимизации хостов и ВМ на них
• Guest Operating Systems - об оптимизации непосредственно гостевых операционных систем
• Virtual Infrastructure Management - лучшие практики для средств управления виртуальной инфраструктурой

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

Очень полезное руководство для тех, кто хочет выжать из своей виртуальной среды максимум. Скачать книгу Performance Best Practices for VMware vSphere 7.0, Update 2 можно по этой ссылке.

В последнее время в продуктах 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 сделала ролик на эту тему:

В начале лета компания VMware выпустила важный документ о сетевой безопасности своей виртуальной среды на базе решения NSX-T, который называется NSX-T Security Reference Guide.

Напомним, что решение VMware NSX-T - это продукт для сетевой виртуализации и агрегации виртуальных сетей датацентров, работающих на базе гибридной среды гипервизоров и контейнеров приложений Kubernetes/Docker.

Документ NSX-T Security Reference Guide представляет собой основное руководство по безопасному построению виртуального сетевого взаимодействия в рамках датацентра на базе платформы VMware vSphere. Основная цель этого руководства - рассказать пользователям NSX-T о лучших практиках построения защищенной сетевой среды, которая соответствует всем современным требованиям с точки зрения безопасности.

Давайте взглянем на основные главы документа:

• NSX Use cases/Customer journey/ Deployment options
• NSX-T Architecture Components
• Virtual Firewalling
• NSX Firewall Policy Building
• Container Security
• Firewall features
• Intrusion Detection and Prevention
• Federation
• Management and Operations

Документ полностью технический и очень детальный - занимает более 140 страниц, поэтому для всех глубоко интересующихся темой безопасности виртуальных сред на базе vSphere/NSX-T будет очень полезен.

Скачивайте!

Многим 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 - утилита NUMA Observer, которая позволяет обнаружить виртуальные машины с перекрытием использования NUMA-узлов на хостах ESXi. При работе с тяжелыми нагрузками, требовательными к Latency, администраторы часто создают affinity-правила по привязке виртуальных машин к NUMA-узлам и ядрам CPU, чтобы они работали быстрее, с наименьшими задержками.

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

С помощью NUMA Observer можно не только обнаруживать перекрытия по использованию ядер CPU и NUMA-узлов со стороны виртуальных машин, но и собирать статистики по использованию памяти дальнего узла и недостатке CPU-ресурсов (метрика CPU Ready). После анализа конфигураций и использования ресурсов, утилита генерирует алерты, которые администратор может использовать как исходные данные при настройке новой конфигурации NUMA-узлов.

Скачать NUMA Observer можно по этой ссылке. После установки сервис доступен через веб-консоль по адресу localhost:8443. Для его работы потребуется Java 8.

Компания VMware выпустила обновление своего решения HCX 4.2, предназначенного для миграции с различных онпремизных инфраструктур (на базе как vSphere, так и Hyper-V или KVM) в облако на платформе VMware vCloud. Напомним, что о возможностях прошлой версии этого продукта мы писали вот тут.

Давайте взглянем на новые фичи VMware HCX 4.2:

1. Оценка времени миграции в реальном времени

Теперь примерное время, оставшееся до конца процесса миграции на базе vMotion, показано на экране задач миграции:

Тут же показывается и время до конца задачи RAV (Replication Assisted vMotion):

2. Предиктивная оценка миграций RAV (Replication Assisted vMotion) 

Используя методики машинного обучения, HCX позволяет оценить комплексную задачу миграции RAV по клику в интерфейсе управления миграциями. Предиктивная оценка вычисляется для RAV и Bulk migrations, например, для группы ВМ (Mobility group):

3. Поддержка OS Assisted Migration (OSAM) для HCX for VMware Cloud

HCX Assisted Migration позволяет автоматизировать процесс миграции с не-vSphere гипервизоров на платформу VMware ESXi. Теперь задачи OSAM можно запустить в облаках VMware Cloud on AWS или Dell EMC.

4. Поддержка кастомных атрибутов (Custom Attributes) для миграций Bulk, RAV и Cold.

Теперь опция Migrate Custom Attributes есть в разделе Extended Options для миграций типа Bulk, RAV и Cold. Значения, ассоциированные с этими атрибутами, теперь учитываются в процессе миграции.

5. Улучшения HCX для VMware Cloud Director / NSX-T 

Этот релиз HCX поддерживает VMware Cloud Director версий 10.2 и 10.3 совместно с решением VMware NSX-T 3.1. Сайт назначения должен иметь один сервер vCenter вместе с решением NSX-T.

Попробовать продукт VMware HCX 4.2 можно на его странице, а посмотреть полный список нововведений можно в Release Notes.

На сайте проекта VMware Labs появилась очередная полезная штуковина - OpenAPI interface for vSphere. Это новый протокол, который является альтернативой SOAP/XML, позволяющий получать доступ к интерфейсам управления VMware vSphere через обмен в JSON-формате. Работа с этим API происходит на базе открытой спецификации OpenAPI.

С помощью OpenAPI interface for vSphere можно получить следующие преимущества:

• Приложения, которые используют REST API и традиционные vSphere Client API могут перейти на один протокол обмена, а значит не нужно поддерживать 2 интерфейса
• Партнеры могут разрабатывать различные дополнения и утилиты для VMware vSphere на базе открытых спецификаций
• Существующие API можно расширять, добавляя новые возможности как в стандартную модель SOAP/XML, так и в новый протокол
• Новый протокол не зависит от существующих API, поэтому не требует доработки сервисов на бэкенде, что ускоряет его внедрение

Новый OpenAPI interface доступен как для написания комплексных независимых сценариев (например, с помощью curl или Postman) в целях автоматизации рутинных задач, так и разработки различных дополнений и компонентов с помощью специального SDK, который будет доступен партнерам VMware.

Разработчикам сценариев также доступны примеры работы простых функций в виде шаблонов, которые можно кастомизировать через CLI-интерфейс. Для работы с OpenAPI вам понадобится:

• vSphere 7.0 или свежее
• Окружение Docker или Kubernetes
• JDK 8 или свежее
• 8 GB RAM

Загрузить компоненты OpenAPI interface for vSphere можно по этой ссылке.

Вильям Лам рассказал о том, как быстро и просто дать пользователям клиента VMware vSphere Client разрешения для просмотра пространств имен (namespaces) кластера vSphere with Tanzu.

Соответствующее разрешение нужно добавить в настройках Single Sign-On клиента:

Single Sign On->Users and Groups-> вкладка Groups

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

После этого пользователю надо разлогиниться и залогиниться снова, а для просмотра пространств имен vSphere with Tanzu будет достаточно базовой роли Read Only для vSphere, которую можно дать разработчику (никаких изменений в конфигурацию чего бы то ни было такой пользователь внести не сможет):

Для пользователей и групп из Active Directory все работает точно таким же образом.

Cormac Hogan, известный специалист в области виртуальных хранилищ на платформе VMware vSphere, выпустил интересное видео об использовании постоянных томов (Persistent Volumes) в качестве файловых шар для кластеров Kubernetes:

В качестве бэкенда таких томов используются файловые шары кластеров VMware vSAN, которые позволяют администраторам Kubernetes контролировать их использование со стороны инфраструктуры контейнеризованных приложений. В видео рассказано о том, как предоставлять права доступа (read only, read/write) на базе параметров сетей, которые получают доступ к томам. Также у Кормака есть детальная статья о том, как эти права доступа настраивать.

Из видео вы узнаете, как шаг за шагом настраивать доступ к томам через конфигурационный файл CSI-драйвера и контролировать сетевой доступ в томам через службы vSAN File Services.

Дункан Эппинг обратил внимание на довольно частую проблему у пользователей VMware vSphere 7, которые делают апгрейд с Update 1 на Update 2. Если вы используете подключение к хранилищам по iSCSI и рандомные имена IQN для инициаторов, то после апгрейда хранилища могут перестать быть доступными, если вы используете контроль доступа на базе IQN.

Проблема проявляется, только если вы создавали подключения по iSCSI именно в vSphere 7 Update 1 на свежей установке. Причина проста - изменился стандарт случайного именования IQN для iSCSI-инициаторов. Если для Update 1 он выглядит так:

iqn.1998-01.com.vmware:labesx06-4ff17c83

То для Update 2 уже так:

iqn.1998-01.com.vmware:labesx07:38717532:64

Соответственно, после апгрейда имя инициатора у вас изменится. Чтобы сделать хранилища iSCSI вновь доступными, надо пойти на дисковый массив или виртуальный модуль (Virtual Appliance) и вбить туда новое имя инициатора. Либо вы можете сделать имя инициатора вручную и вбить его также и на массиве для нужных LUN.

Кстати, при апгрейде с версии vSphere 6.7 или vSphere 7 сразу на Update 2 проблема не возникает, так как настройки iSCSI корректно переезжают сразу в configstore.

Чтобы изменить имя iSCSI-адаптера, можно использовать вот эту команду, чтобы это имя получить:

$ esxcli iscsi adapter get -A vmhba67

Вывод будет, например, таким:

vmhba67
Name: iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

И потом вот эту команду, чтобы задать новое имя:

$ esxcli iscsi adapter set -A vmhba67 -n iqn.1998-01.com.vmware:w1-hs3-n2503.eng.vmware.com:452738760:67

Также можно это сделать и с помощью PowerCLI-сценария (подробнее тут):

Get-VMHost |
ForEach-Object -Process {
    $HostHBA = $_ | Get-VMHostHba -Type iScsi | Select-Object Name,IScsiName
    $esxcli = get-esxcli -v2 -vmhost $_
    $CLIARG =  @{
        adapter = $HostHBA.Name
        name = $HostHBA.IScsiName
        skipifsessionactive = $false
        }
    $esxcli.iscsi.adapter.set.Invoke($CLIARG)
write-host "Setting host " $H  "adapter"  $HostHBA.Name "with IQN" $HostHBA.IScsiName
    }

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

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

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a. Также мы рассказывали о том, как зайти в консоль вспомогательных виртуальных машин VM Service.

Пару недель назад Cormac Hogan выпустил интересное видео для разработчиков и администраторов, в котором показывается, как можно создавать виртуальные машины на базе vSphere with Tanzu с помощью YAML-манифеста для пользовательских данных и ВМ:

Ну и, конечно же, рекомендуем отличную статью "A first look at vSphere VM Service" от автора видео.

Если у вас большая Enterprise-инсталляция VMware vSphere, и вам хочется оповещать пользователей о каких-либо важных статусах, изменениях или новостях, то вы можете использовать механизм Message of the Day (MotD) - сообщение, которое появляется в верхней части экрана vSphere Client. Например, пользователям можно сообщить, что они работают в Sandbox-окружении:

Вильям Лам рассказал о том, как правильно можно работать с этим с точки зрения автоматизации. В интерфейсе это сообщение можно настроить в разделе Configure->Settings->Message of Day:

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

Ну и главное - как это автоматизировать, если у вас несколько окружений vCenter?

Вот такой командой можно получить сообщение дня через PowerCLI:

Get-AdvancedSetting -Entity $global:DefaultVIServer -Name vpxd.motd | select Value

К сожалению, с помощью Set-AdvancedSetting нельзя установить это сообщение, так как для обертки API это свойство находится в статусе Read Only. Поэтому нужно использовать API напрямую.

Вот так можно посмотреть текущий MotD:

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.Message

А вот так - обновить его:

$motd = "This is William Lam's environment, it is NOT supported. Use at your own risk"

$sm = Get-View $global:DefaultVIServer.ExtensionData.Content.SessionManager

$sm.UpdateServiceMessage($motd)

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

А сделано тут было 3 важных вещи:

• Пакет NVIDIA AI Enterprise Suite был сертифицирован для vSphere
• Появилась поддержка последних поколений GPU от NVIDIA на базе архитектуры Ampere  
• Добавились оптимизации в vSphere в плане коммуникации device-to-device на шине PCI, что дает преимущества в производительности для технологии NVIDIA GPUDirect RDMA

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

1. NVIDIA AI Enterprise Suite сертифицирован для vSphere

Основная новость об этом находится в блоге NVIDIA. Сотрудничество двух компаний привело к тому, что комплект программного обеспечения для AI-аналитики и Data Science теперь сертифицирован для vSphere и оптимизирован для работы на этой платформе.

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

2. Поддержка последнего поколения NVIDIA GPU

Последнее поколение графических карт для ML-задач, Ampere Series A100 GPU от NVIDIA, имеет поддержку Multi-Instance GPU (MIG) и работает на платформе vSphere 7 Update 2.

Графический процессор NVIDIA A100 GPU, предназначенный для задач машинного обучения и самый мощный от NVIDIA на сегодняшний день в этой нише, теперь полностью поддерживается вместе с технологией MIG. Более детально об этом можно почитать вот тут. Также для этих карт поддерживается vMotion и DRS виртуальных машин.

Классический time-sliced vGPU подход подразумевает выполнение задач на всех ядрах GPU (они же streaming multiprocessors, SM), где происходит разделение задач по времени исполнения на базе алгоритмов fair-share, equal share или best effort (подробнее тут). Это не дает полной аппаратной изоляции и работает в рамках выделенной framebuffer memory конкретной виртуальной машины в соответствии с политикой.

При выборе профиля vGPU на хосте с карточкой A100 можно выбрать объем framebuffer memory (то есть памяти GPU) для виртуальной машины (это число в гигабайтах перед буквой c, в данном случае 5 ГБ):

Для режима MIG виртуальной машине выделяются определенные SM-процессоры, заданный объем framebuffer memory на самом GPU и выделяются отдельные пути коммуникации между ними (cross-bars, кэши и т.п.).

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

Первая цифра сразу после a100 - это число слайсов (slices), которые выделяются данной ВМ. Один слайс содержит 14 процессоров SM, которые будут использоваться только под эту нагрузку. Число доступных слайсов зависит от модели графической карты и числа ядер GPU на ней. По-сути, MIG - это настоящий параллелизм, а обычный режим работы - это все же последовательное выполнение задач из общей очереди.

Например, доступные 8 memory (framebuffers) слотов и 7 compute (slices) слотов с помощью профилей можно разбить в какой угодно комбинации по виртуальным машинам на хосте (необязательно разбивать на равные части):

3. Улучшения GPUDirect RDMA

Есть классы ML-задач, которые выходят за рамки одной графической карты, какой бы мощной она ни была - например, задачи распределенной тренировки (distributed training). В этом случае критически важной становится коммуникация между адаптерами на нескольких хостах по высокопроизводительному каналу RDMA.

Механизм прямой коммуникации через шину PCIe реализуется через Address Translation Service (ATS), который является частью стандарта PCIe и позволяет графической карточке напрямую отдавать данные в сеть, минуя CPU и память хоста, которые далее идут по высокоскоростному каналу GPUDirect RDMA. На стороне приемника все происходит полностью аналогичным образом. Это гораздо более производительно, чем стандартная схема сетевого обмена, об этом можно почитать вот тут.

Режим ATS включен по умолчанию. Для его работы карточки GPU и сетевой адаптер должны быть назначены одной ВМ. GPU должен быть в режиме Passthrough или vGPU (эта поддержка появилась только в vSphere 7 U2). Для сетевой карты должен быть настроен проброс функций SR-IOV к данной ВМ.

Более подробно обо всем этом вы можете прочитать на ресурсах VMware и NVIDIA.

На сайте проекта 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 можно по этой ссылке.

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

Вильям Ламм рассказал о простом способе ограничения доступа к UI клиента vSphere Client. Делается это через настройки сервера Apache Tomcat, на базе которого построен виртуальный модуль vCenter Server Appliance. Называется это Access Control Valve - по ссылке можно подробно изучить опции, которые можно применять, а мы же рассмотрим простой пример ниже.

Идем по SSH на vCSA и открываем там следующий файл:

/usr/lib/vmware-vsphere-ui/server/conf/context.xml 

В него добавляем следующую запись:

<Valve className="org.apache.catalina.valves.RemoteAddrValve" allow="127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost|x.x.x.x|y.y.y.y"/>

Значения x.x.x.x, y.y.y.y и далее за ними можно указать как разрешенные адреса для соединения с сервером. Блок "127\.\d+\.\d+\.\d+|::1|0:0:0:0:0:0:0:1|localhost" должен присутствовать всегда для обеспечения локального соединения сервисов самого vCenter.

Адреса, не занесенные в этот список, при соединении через веб-браузер получат 403 ошибку, при этом доступ через PowerCLI и API останется для этих адресов (поскольку это только настройка веб-сервера):

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

service-control --restart vsphere-ui

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

Итак, для начала выводим список доступных USB-интерфейсов на сервере:

esxcli hardware usb passthrough device list

У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):

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

esxcli hardware usb passthrough device disable -d 2:7:90c:1000

После этого будет вот такая картина:

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

Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:

esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1

Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:

vdq -q

Затем создаем переменную с именем устройства, например:

DEVICE_NAME="t10.JMicron_Generic_________0123456789ABCDEF"

Затем выполняем следующие команды для создания SATP-правила и перезагрузки устройства, которое подцепится как SSD-хранилище:

esxcli storage nmp satp rule add -s VMW_SATP_LOCAL --device=${DEVICE_NAME} --option=enable_ssd

esxcli storage core claiming unclaim --type device --device=${DEVICE_NAME}

esxcli storage core claimrule load

esxcli storage core claimrule run

Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:

Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.

Создаем переменную с полным путем к устройству:

DEVICE_PATH="/vmfs/devices/disks/t10.JMicron_Generic_________0123456789ABCDEF"

Далее выполняем команду, которая разметит наш том как VMFS:

partedUtil mklabel ${DEVICE_PATH} msdos

END_SECTOR=$(eval expr $(partedUtil getptbl ${DEVICE_PATH} | tail -1 | awk '{print $1 " \\* " $2 " \\* " $3}') - 1)

/sbin/partedUtil "setptbl" "${DEVICE_PATH}" "gpt" "1 2048 ${END_SECTOR} AA31E02A400F11DB9590000C2911D1B8 0"

/sbin/vmkfstools -C vmfs6 -b 1m -S $(hostname -s)-local-usb-ssd-datastore ${DEVICE_PATH}:1

Если все в порядке, вы увидите новый том в списке VMFS-томов в vSphere Client:

Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).

Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.

Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.

Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:

Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).

Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:

configstorecli config current get -g cluster -c ha -k fdm
{
   "mem_reservation_MB": 200,
   "memory_checker_time_in_secs": 0
}

Все это можно также экспортировать в json-файл командой:

configstorecli config current get -g cluster -c ha -k fdm > test.json

Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:

{
    "mem_reservation_MB": 200,
    "memory_checker_time_in_secs": 0,
    "node_goodness": 10000000
}

И импортируем его обратно в ConfigStore:

configstorecli config current set -g cluster -c ha -k fdm -infile test.json

В итоге хост ESXi 1507 был Primary:

А затем им стал узел 1505, для которого мы изменили данную расширенную настройку:

Ну и Дункан записал небольшое видео, раскрывающее весь процесс изменения данных настроек в VMware FDM / HA:

Недавно мы писали о VM Service - службе, которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин. Она была анонсирована в vSphere 7 Update 2a.

Многие пользователи жалуются, что консоль виртуальных машин, развернутых через VM Service в кластере vSphere with Tanzu, оказывается недоступна для логина, даже для администраторов. Над этой проблемой работают, но пока в интерфейсе это выглядит так:

Между тем, попасть в консоль иногда нужно (например, для отладки или траблшутинга) - и для этого есть воркэраунд.

Итак, заходим по SSH на VMware vCenter Server Appliance (vCSA) и выполняем следующие команды, которые получают root-пароль от Supervisor Cluster, выводят его в консоли и инициируют сессию к одному из узлов супервизор-кластера:

SV_DECRYPT_OUTPUT=$(/usr/lib/vmware-wcp/decryptK8Pwd.py)

SV_CLUSTER_IP=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'IP: ' '{print $2}' | awk '{print $1}')

SV_CLUSTER_ROOT_PASSWORD=$(echo ${SV_DECRYPT_OUTPUT} | awk -F 'PWD: ' '{print $2}' | awk '{print $1}')

echo -e "\n${SV_CLUSTER_ROOT_PASSWORD}\n"

ssh root@${SV_CLUSTER_IP}

Далее, после того, как мы залогинились в Supervisor Cluster, нужно получить креды от нужного нам узла. Делается это следующим набором команд:

VM_SERVICE_ACCOUNT_USERNAME=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.password}' | base64 -d)
VM_SERVICE_ACCOUNT_PASSWORD=$(kubectl get secrets wcp-vmop-sa-vc-auth -n vmware-system-vmop -o jsonpath='{.data.username}' |base64 -d)
echo -e "\n${VM_SERVICE_ACCOUNT_PASSWORD}\n${VM_SERVICE_ACCOUNT_USERNAME}\n"

После этого заходим в vSphere Client под этими кредами и функция запуска консоли для данной ВМ вам будет доступна:

Источник.

Многие из вас, наверняка, знакомы с инфраструктурой публичного облака VMware Cloud on AWS, которая была анонсирована еще летом 2017 года. Это все та же платформа VMware vSphere, все те же серверы VMware ESXi, но стоят они физически в датацентрах Amazon. Все это управляется совершенно нативно для инфраструктуры vSphere, туда же включаются и решение...

Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.

Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):

Failed to load crypto64.efi

Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.

Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:

• Supervisor Cluster
  • Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
  • Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
• Tanzu Kubernetes Grid Service for vSphere
  • Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
  • Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
  • Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.

Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-7.0U2a-17867351-standard \

-d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Скачать VMware vSphere 7 Update 2a можно по этой ссылке. Release notes доступны тут.

В вышедшем на днях обновлении VMware vSphere 7 Update 2a (обновился только vCenter) компания VMware представила службу vSphere Virtual Machine Service (она же VM Service), которая дает разработчикам и администраторам, работающих со средой контейнеров Kubernetes в решении vSphere with Tanzu, возможности по развертыванию виртуальных машин.

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

Служба VM Service дополняет ранее анонсированные службы Network Service и Storage Service, которые дают возможности по управлению через API сетью и хранилищем, соответственно, в среде vSphere with Tanzu. Вот хороший обзор новых функций VM Service:

Со стороны vSphere служба встроена напрямую в vCenter, она позволяет управлять образами ВМ (VM Images / Content Libraries) и классами ВМ (VM Classes / VM sizing).

Со стороны Kubernetes компонент называется VM Operator, он создает и обслуживает ресурсы Kubernetes Custom Resources (CRs/CRDs), а также общается с компонентом на стороне vSphere.

VM Service даст компаниям следующие преимущества:

• Разработчикам в среде Kubernetes больше не требуется создавать заявки на создание ВМ для администраторов.
• Администратор может преконфигурировать заданные классы ВМ, доступные разработчикам, задав лимиты их ресурсов, а также обеспечив защиту и изоляцию от продуктивного окружения.
• Некоторые приложения в контейнерах, например, могут использовать базу данных, размещенную в ВМ. В этом случае разработчик сможет создать спецификацию такого сервиса в YAML и обслуживать такую структуру самостоятельно.
• Open Source природа сервиса позволит дорабатывать и создавать новые службы с учетом потребностей больших команд. Репозиторий компонента VM Operator находится тут.

Более подробно о службе vSphere Virtual Machine Service рассказано в этой статье. Служба VM Service доступна в последнем релизе VMware vSphere 7 Update 2a.

На сайте проекта VMware Labs обновился основной клиент VMware vSphere на базе технологии HTML5 (он же vSphere Client в составе платформы VMware). Напомним, что старый клиент Web Client на базе Adobe Flex ушел в прошлое, и VMware предлагает использовать только новый клиент для управления виртуальной инфраструктурой.

Кстати, VMware vSphere HTML5 Web Client версии 5.0 (build 15670023) - это первое обновление клиента за довольно долгое время. Давайте посмотрим, что там появилось нового:

• Обновлена документация (в том числе инструкции, где находятся файлы и сервисы клиента)
• Добавлен новый язык для функции Code Capture - теперь записанные во время сессии действия могут транслироваться в код на языке Go.
• PowerActions - это новый механизм интеграции PowerCLI и vSphere Client. Теперь в клиенте есть функциональность по запуску отдельных команд и сценариев PowerCLI, а также функции их хранения в библиотеке скриптов. Исполнение кастомных действий скриптов можно привязать к объектам из inventory в клиенте.
• Функцию PowerActions надо включать отдельно при развертывании клиента (см. документ PowerActions_documentation_Fling50.pdf).

Базовая операционная система виртуального модуля vSphere Client была заменена на Photon OS, поэтому апгрейд с прошлой версии не поддерживается - придется развертывать все по-новой.

Загрузить новую версию клиента VMware vSphere HTML5 Web Client 5.0 можно по этой ссылке. Инструкции по установке и использованию доступны тут. Также много всего интересного есть в комбо-боксе выбора компонентов загрузки:

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

Оказывается, в весеннем обновлении VMware vSphere 7 Update 2 появилась поддержка нового механизма Precision Time for Windows. Раньше для почти всех задач в виртуальных машинах использовалась связка NTP+Active Directory, которая работает отлично в подавляющем большинстве случаев. NTP обеспечивает точность на уровне миллисекунд, а если нужна какая-то большая точность (например, финансовые приложения), то тут можно использовать специальное оборудование с поддержкой PTP (Precision Time Protocol).

VMware решила сделать еще одно улучшение для пользователей, которым требуется повышенная чувствительность служб точного времени. Теперь в vSphere 7 Update 2 есть поддержка Precision Time for Windows - механизма, который улучшает точность синхронизации времени в ОС Windows.

Сервис Windows Time Service (W32Time) - это служба, которая опирается на NTP и предоставляет клиентам ОС информацию о точном времени. В основном она нужна для синхронизации времени между хостами в Active Directory, но уже вышла за рамки этих задач и может быть использована приложениями. Архитектура W32Time построена на базе плагинов, что означает, что DLL-библиотека может быть зарегистрирована как провайдер служб точного времени. Это могут быть как чисто программные решения, так и комплексные системы со специальным оборудованием с поддержкой PTP-протокола.

API-интерфейсы для разработки таких плагинов находятся в открытом доступе, каждый может написать свой собственный. Вот и VMware разработала свой VMware Time Provider (vmwTimeProvider), который поставляется вместе с VMware Tools для ВМ на базе Windows. Он получает время от виртуального устройства Precision Clock (оно появилось еще в vSphere 7.0) и передает его на сторону W32Time по закрытому и быстрому каналу (на базе технологии паравиртуализации), минуя сетевой стек.

vmwTimeProvider - это плагин, работающий в пространстве user-space. По идее такое устройство требовало бы собственный драйвер, но у VMware есть собственный паравиртуализованный интерфейс, который использует преимущества технологии Memory-mapped I/O (MMIO), оптимизированной под операции чтения.

Устройство Precision Clock получает время от ядра гипервизора (VMkernel), одним из источников является устройство HyperClock, поставляющее в ядро системное время. Таким образом, если вы настроите VMkernel и HyperClock на получение времени через Precision Time Protocol (PTP), то устройство Precision Clock будет передавать его в виртуальные машины с большой точностью.

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

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

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

• Модернизации, мониторинга и запуска приложений
• Миграции в облако
• Сетей и безопасности

Каждый вторник и четверг с 16 марта по 1 июня на вебинарах VMware будет рассказывать:

• Как поменялась архитектура сетевых функций после прихода программной определяемости
• Какие непривычные возможности получают привычные инструменты ИБ, когда они работают на уровне платформы
• Какие новые технологии в области виртуализации и информационной безопасности нас ждут
• Какие инструменты есть у VMware для управления частными и гибридными облаками
• Почему важно следить за использованием ресурсов и при чем здесь инструменты Инфраструктуры-как-код

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

Если вы не успели на первую часть вебинаров, вы можете посмотреть записи на YouTube-канале: https://www.youtube.com/watch?v=u3C3kEvuO_w&list=PLSHgmTQvHHVFg6C-d6_ncX8O0buyY0Jce

По итогам каждого вебинара проводится розыгрыш призов.

Зарегистрироваться на бесплатные вебинары VMware можно по этой ссылке: https://via.vmw.com/ERkW.