Новости Статьи VMware Veeam StarWind vStack Microsoft Nakivo Citrix Symantec События Релизы Видео Контакты Авторы RSS
Виртуализация и виртуальные машины

Все самое нужное о виртуализации и облаках

Более 6290 заметок о VMware, AWS, Azure, Veeam, Kubernetes и других

VM Guru | Ссылка дня: Полный список лабораторных работ VMware Hands-on Labs

3 обновления утилит на VMware Labs: OS Optimization Tool, USB Network Native Driver for ESXi и App Volumes Migration Utility


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

1. Новая версия OS Optimization Tool b1171

Последний раз эту утилиту обновляли в начале августа этого года (b1170). Напомним, что она предназначена для подготовки гостевых ОС к развертыванию и проведению тюнинга реестра в целях оптимизации производительности, а также отключения ненужных сервисов и запланированных задач.

Что интересного в этом обновлении:

  • Пункт Disable Passive Polling больше не выбран по умолчанию (некоторые приложения думали, что отсутствует интернет соединение).
  • Новая настройка - использовать графический драйвер WDDM для подключений через Remote Desktop.
  • Новая функция поиска по оптимизациям, чтобы найти отдельные объекты. Это доступно на вкладках Optimize и My Templates.
  • Добавлен сплиттер для расширения зоны дерева слева в разделе My Templates.
  • Новые контролы для управления поиском Cortana и поведением окошка поиска в таскбаре.
  • Новая опция для указания аккаунта администратора, чтобы выполнять операции после отработавшего SysPrep (по умолчанию это текущий пользователь, который добавляется в группу Администраторы).
  • Исправлено много ошибок.

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

2. Обновление USB Network Native Driver for ESXi 1.6

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

Что появилось нового:

  • Добавлена поддержка устройств Aquantia и Trendnet AQC111U (0xe05a:0x20f4).
  • Добавлена поддержка Realtek RTL8153 (0x045e:0x07c6).
  • Поддержка Realtek RTL8156 (0x0bda:0x8156).
  • Поддержка постоянных маппингов MAC-адресов VMkernel на USB NIC.
  • Упрощенное сохранения состояния USB NIC.
  • Решена проблема со скоростью соединения для чипсетов RTL8153.
  • Это последний релиз, поддерживающий ESXi 6.5.

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

3. Новая версия App Volumes Migration Utility 1.0.4

Эта штука позволяет смигрировать старые объекты AppStacks, в которых распространялись приложения в VMware App Volumes 2.18, на новый формат VMware App Volumes 4.0, который реализует концепцию приложений и пакетов. Подробно мы писали об этой утилите вот тут.

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


Таги: VMware, Labs, Update, Optimization, USB, ESXi, App Volumes

Обновление продуктов VMware vSphere 6.7 Update 3 - vCenter и ESXi


На днях компания VMware обновила пару продуктов линейки серверной платформы, выпустив обновления компонентов vSphere 6.7 Update 3:

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

vCenter 6.7 Update 3j
  • Поддержка SMTP-аутентификации в виртуальном модуле vCenter Server Appliance для отсылки алертов и алармов по почте в защищенном режиме. Можно также использовать и анонимный режим.
  • Еженедельное оповещение о приближении устаревания сертификатов для служб vCenter Single Sign-On Security Token Service (STS). Напоминалки начинаются за 90 дней и появляются каждую неделю.
  • Через Managed Object Browser можно сделать hard stop виртуальной машины на случай, если это невозможно сделать из гостевой ОС. Формат вызова такой: https://10.100.200.300/mob/?moid=vm-518&method=terminate
  • Обновления базовой операционной системы Photon OS.

Release notes доступны тут.

ESXi 6.7 Update 3 Build 16713306

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

VMware Tools 11.1.5

В основном, этот релиз содержит исправления ошибок, полный список фиксов доступен тут. Также обновился openssl до версии 1.0.2v. Пакеты VMware Tools для Windows подписаны сертификатами Microsoft на базе SHA-2.

Небольшое обновление ESXi 6.5 Update 3 PO5

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

Скачать VMware vSphere 6.7 Update 3 и обновленный vCenter 6.7 Update 3j можно по этой ссылке.


Таги: VMware, vCenter, Update, vSphere, ESXi

Откат (rollback) к прошлой версии VMware ESXi после апгрейда, если что-то пошло не так


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

Для этого нужно во время установки выбрать пункт "Upgrade ESXi, preserver VMFS datastore". Под датастором тут имеется в виду, что на нем сохранится предыдущая установка ESXi:

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

Сделать апгрейд на ESXi 7 с сохранением предыдущей версии платформы не выйдет - в VMware vSphere 7 поменялась структура разделов гипервизора ESXi.

Итак, вы сделали апгрейд ESXi, но что-то пошло не так. Например, ваше железо больше не поддерживается (к примеру, CPU), и вам надо сделать откат к прошлой версии ESXi. Для этого во время загрузки вам нужно нажать комбинацию клавиш Shift + <R>:

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

Также можно делать бэкап и восстановление конфигурации VMware ESXi - об этом рассказано в KB 2042141.


Таги: VMware, vSphere, Upgrade, ESXi, Обучение, Storage

Установка VMware ESXi 7.0 на старом железе - что можно сделать?


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

  • Intel Family 6, Model = 2C (Westmere-EP)
  • Intel Family 6, Model = 2F (Westmere-EX)

Однако для тех, кому очень надо, компания VMware оставила небольшую возможность все-таки установить ESXi 7.0 на старом железе со старыми процессорами, но без каких-либо гарантий по работоспособности и поддержке (то есть, статус у этого режима - unsupported). В частности, коллеги написали статью об установке vSphere 7 на сервер IBM M3 X3550 Series.

Для начала решили ставить ESXi на USB-диск, так как RAID-контроллер сервера больше не поддерживается со стороны ESXi 7:

Далее при загрузке установщика ESXi с CD-ROM или ISO нужно нажать комбинацию клавиш Shift + <O> (это буква, а не ноль), после чего появится приглашение ко вводу. Надо ввести вот такую строчку в дополняемую строку:

allowLegacyCPU=true

Далее для установки выбрали USB-диск и начали установку ESXi на него:

После того, как ESXi установится на ваш сервер, вам нужно будет снова нажать Shift + <O> и повторно вбить указанный выше параметр при первом запуске:

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

Далее подключаемся к ESXi по SSH и с помощью следующей команды находим файл конфигурации загрузки:

find / -name "boot.cfg

Далее добавляем в него параметр allowLegacyCPU=true в разделе kernelopt:

Два загрузочных модуля ESXi находятся в директориях /bootbank и /altbootbank. На всякий случай надо поменять boot.cfg в обеих директориях.

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

Ну и, собственно, сам сервер ESXi 7.0.0, нормально работающий на сервере IBM x3550 M3:

Бонусом шутка про редактор vi, которым редактировался файл boot.cfg:


Таги: VMware, ESXi, CPU, Support, HCL, vSphere, Blogs

Улучшения механизма Storage vMotion в VMware 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, vSphere, SVMotion, Update, ESXi, Storage, VMachines

Что изменилось в структуре дисковых разделов (Partition Layout) на платформе 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 с таких устройств, если они были созданы установщиком по умолчанию.


Таги: VMware, vSphere, ESXi, Storage, Hardware, USB, SSD

10 главных причин обновиться на VMware vSphere 7


Как вы знаете, компания VMware выпустила платформу VMware vSphere 7 в начале апреля этого года после громкого анонса месяцем ранее. В конце апреля VMware опубликовала интересную новость с результатами исследования среди пользователей, которые тестировали бета-версию vSphere 7 и потом прошли опрос, где одним из вопросов был "Почему бы вы хотели обновиться?". Собственно, вот его результаты...


Таги: VMware, vSphere, Upgrade, vCenter, ESXi

Обновленная книга "Performance Best Practices for VMware vSphere 7.0"


Компания 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, vSphere, Performance, Whitepaper, ESXi, vCenter, VMachines, Update

VMware продлила поддержку vSphere 6.7 в связи с пандемией


Компания 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, vSphere, Support, ESXi

Обзор процесса апгрейда хостов на VMware ESXi 7 средствами VMware Lifecycle Manager


Как все уже знают, в новой версии платформы виртуализации 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.


Таги: VMware, vSphere, Upgrade, ESXi, Blogs, Обучение, vLCM, Lifecycle

Как пробросить USB-клавиатуру или мышь в гостевую ОС виртуальной машины на VMware vSphere?


Вильям Лам написал интересную заметку о том, как пробросить 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-устройства с хоста.


Таги: VMware, USB, Hardware, ESXi, vSphere

Мелочь, а приятно: миграция vMotion для виртуальных машин с привязанными ISO в VMware vSphere 7


Frank Denneman обратил внимание на одну интересную новую функцию VMware vSphere 7 - возможность миграции vMotion для виртуальных машин с привязанными ISO-образами.

Как знают администраторы vSphere, часто приходится привязывать ISO-образ к консоли виртуальной машины, чтобы установить какое-то ПО. Нередко этот ISO находится на локальном хранилище машины администратора:

В таком случае, при попытке миграции vMotion данной виртуальной машины выдается ошибка о невозможности выполнения операции в связи с привязанным и активным локальным ISO к виртуальному устройству CD/DVD:

Усугубляется это еще и тем, что такие машины исключаются из миграций DRS, а также не могут быть смигрированы автоматически при переводе хоста ESXi в режим обслуживания (Maintenance mode). Как это обычно бывает, администратор узнает об этом в самом конце, минут через 10 после начала операции по переводу на обслуживание - и агрится от такой ситуации.

Поэтому в VMware vSphere 7 такое поведение пофиксили: теперь при миграции vMotion виртуальное устройство с локальным файлом отсоединяется от исходной машины по команде процесса VMX, все операции с ним буферизуются, далее происходит миграция машины на другой хост, подцепление к нему виртуального устройства с вашим ISO и накатывание буфера.

После переключения машины на другой хост ESXi, VMRC-консоль показывает подключение вашего локального ISO уже к целевой машине:

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


Таги: VMware, vMotion, ESXi, vSphere, Storage

Новое на VMware Labs: виртуальный модуль Demo Appliance for Tanzu Kubernetes Grid


На сайте проекта VMware Labs появилась очередная полезная штука - виртуальный демо-модуль Demo Appliance for Tanzu Kubernetes Grid, с помощью которого администраторы платформ vSphere и Kubernetes могут протестировать инфраструктуру контейнеризованных приложений в виртуальных машинах.

В состав модуля входят все необходимые компоненты для того, чтобы пользователи могли научиться работе с кластерами Tanzu Kubernetes Grid (TKG) в облаке VMware Cloud on AWS, либо в инфраструктуре vSphere 6.7 Update 3. Это решение можно использовать только в образовательных целях или в рамках тестирования, для производственной среды оно не предназначено.

С помощью данного виртуального модуля за менее чем 30 минут можно развернуть инфраструктуру Kubernetes, имея только SSH-клиент и веб браузер. Работает это следующим образом:

Возможности решения TKG Demo Appliance:

  • Быстрое развертывания кластеров TKG в облаке или онпремизной инфраструктуре vSphere.
  • Онлайн-библиотека vSphere Content Library для синхронизации всех связей решения TKG Demo Appliance.
  • Пошаговое интерактивное руководство по развертыванию и использованию.
  • Предзагруженный реестр Harbor со всеми необходимыми компонентами TKG и демо-контейнерами.
  • Поддержка изолированных окружений (Air-Gapped) и окружений без интернета.
  • Примеры демо-приложений, включая Persistent Volume и приложение K8s 3-Tier Application с балансировщиком нагрузки.
  • Простой доступ к кластерам и их отладка с помощью Octant.
Что включено в состав демо-решения:
  • Командный интерфейс Tanzu Kubernetes Grid (TKG) CLI
  • Компонент Harbor
  • Командный интерфейс Tanzu Mission Control CLI
  • Решение Octant для визуализации кластера Kubernetes на дэшборде с точки зрения пространств имен и объектов, которые они содержат
  • Командный интерфейс Kubectl CLI
  • Компонент Docker Compose

Скачать Demo Appliance for Tanzu Kubernetes Grid можно по этой ссылке.


Таги: VMware, Tanzu, Kubernetes, Labs, TKG, vSphere, ESXi

Что такое и как включить VMware ESXi Quick Boot?


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

Ведь для некоторых обновлений и патчей необязательно аппаратно перезагружать хост и реинициализировать все его оборудование, что происходит при стандартной загрузке (процесс power-on self-test, POST). Достаточно лишь перезагрузить программную часть платформы.

Возможность быстрой перезагрузки ESXi Quick Boot может быть использована компонентами vSphere Update Manager или vSphere Lifecycle Manager (vLCM). 

Надо отметить, что функции Quick Boot доступны не для всех серверов. Более подробная информация по этому поводу приведена в KB 52477, а вот ссылки на страницы вендоров серверного оборудования, где можно узнать детали поддержки этой технологии:

Для корректной работы Quick Boot есть и некоторые ограничения. Если вы используете vSphere 6.7, то Quick Boot не будет работать, если у вас включен TPM, есть устройства passthru, а также загружены драйверы vmklinux. Для версии vSphere 7.0 ограничением является только включенный TPM.

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

/usr/lib/vmware/loadesx/bin/loadESXCheckCompat.py

Включить быструю загрузку можно в настройках Update Manager или Lifecycle Manager через vSphere Client или Web Client (этот клиент доступен только для vSphere 6.7):


Таги: VMware, ESXi, vSphere, Update, Update Manager, Lifecycle Manager, vLCM, VUM

Депрекация Integrated Windows Authentication (IWA) в VMware vSphere 7 - что это значит?


Не так давно мы писали о той функциональности, которой уже нет в VMware vSphere 7, а также о том, какие фичи находятся в состоянии Deprecated. Это значит, что они пока еще есть в текущем релизе, но уже точно будут отсутствовать в следующей версии платформы. Одной из таких фич стала аутентификация Integrated Windows Authentication (IWA), она же "встроенная проверка подлинности Windows".

IWA - это механизм, который позволяет аутентифицироваться через встроенную аутентификацию ОС в сервисах сервера vCenter, который подключен к домену Microsoft Windows Active Directory (AD).

Депрекация этого механизма в vSphere 7 означает, что вы все еще можете смигрировать настройки IWA при апгрейде vCenter, а также развернуть его с нуля. После этого IWA позволит пользователям аутентифицироваться на vCenter.

Почему поддержка IWA уходит из vSphere? Ответ прост - раньше vCenter работал на платформе Windows как приложение для этой ОС с соответствующими возможностями доступа к ее функциям и сервисам AD, теперь же это виртуальный модуль (vCenter Server Appliance), который работает на базе Linux (а точнее Photon OS) и не может быть нативной частью домена.

Какие альтернативные способы можно использовать для аутентификации в домене AD:

  • С использованием LDAP. Контроллеры домена предоставляют сервисы LDAP, которые может использовать vCenter.
  • С использованием нового механизма Identity Federation (появился в версии vSphere 7). Эту возможность можно применять для соединения vCenter к Active Directory Federation Services (ADFS) с использованием протоколов OAUTH2 и OIDC.

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

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

Аналогичный подход к депрекации IWA компания VMware сделала и для серверов ESXi - они будут поддерживать взаимодействие с доменом на тех же условиях, что и vCenter. Правами доступа к хост-серверам ESXi можно управлять через стандартный механизм Role-Based Access Controls (RBAC) на сервере vCenter.

Поэтому по совокупности причин было решено отказаться от IWA в пользу более гибкого механизма LDAP/LDAPS.

Кстати, если вы видите в логе контроллера домена событие Event 2889 при использовании IWA, то обратитесь к статье KB 78644.

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

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


Таги: VMware, vSphere, Security, vCenter, ESXi, Microsoft

Медленная скорость чтения с NFS-хранилищ со стороны серверов VMware ESXi, и как это исправить


Недавно компания VMware выпустила интересный документ, объясняющий иногда возникающие проблемы с производительностью операций чтения с NFS-хранилищ для серверов VMware ESXi версий 6.x и 7.x. В документе "ESXi NFS Read Performance: TCP Interaction between Slow Start and Delayed Acknowledgement" рассматривается ситуация с эффектом Slow Start и Delayed Acknowledgement.

Этот эффект возникает в некоторых сценариях с низким процентом потери пакетов (packet loss), когда используется fast retransmit на передатчике и selective acknowledgement (SACK) на приемнике. Для некоторых реализаций стека TCP/IP в случаях, когда передатчик входит в состояние slow start при включенной отложенной квитанции приема пакетов (delayed ACK), квитанция о приеме первого сегмента slow start может быть отложена на время до 100 миллисекунд. Этого оказывается достаточно, чтобы снизить последовательную скорость чтения с NFS-хранилища на величину до 35% (при этом потери пакетов не будут превышать 0.02%).

Более подробно механика возникновения этого эффекта описана в документе. Там же рассказывается и метод борьбы с этим: если вы подозреваете, что у вас подобная проблема, надо просто отключить ESXi NFS Client Delayed ACK и посмотреть, стало ли лучше. Для этого в консоли нужно выполнить следующую команду:

esxcli system settings advanced set -o "/SunRPC/SetNoDelayedAck" -i 1

После этого убеждаемся, что настройка установлена:

esxcli system settings advanced list | grep -A10 /SunRPC/SetNoDelayedAck

Более подробно об этом можно также почитать в KB 59548.

После этого нужно снова провести тесты на последовательное чтение. Если не помогло, то лучше вернуть настройку назад, указав в качестве параметра первой команды -i 0.


Таги: VMware, Performance, Storage, NFS, ESXi, vSphere, Whitepaper

Вышли обновления VMware vCenter Server 6.7 Update 3g и ESXi 6.7 Update 3 P02


Компания VMware выпустила небольшие обновления инфраструктуры виртуализации VMware vSphere 6.7 - на днях вышли апдейты vCenter Server 6.7 Update 3g и ESXi 6.7 Update 3 P02.

Более-менее заметные изменения появились только в vCenter 6.7 U3g:

  • Появился аларм Replication State Change для виртуального модуля vCSA с Embedded Platform Services Controller, который возникает при переходе репликации между инстансами в статус READ_ONLY. При возвращении в статус Normal аларм исчезает.
  • Теперь можно использовать утилиту sso-config для замены сертификата Security Token Service (STS).
  • Несколько исправлений ошибок, приведенных в разделе Resolved Issues.
  • Обновления Photon OS, о которых можно почитать вот тут.

Обновление ESXi 6.7 Update 3 P02 включает в себя только патчи подсистемы безопасности, а также апдейты драйверов устройств. Более подробно об этом написано вот тут. Скачать это обновление можно через Update Manager или вручную с этой страницы (а далее установить с помощью команды esxcli software vib).


Таги: VMware, vCenter, Update, ESXi, vSphere

Проверки VMware vSphere Lifecycle Manager (vLCM) Compatibility Checks - как они работают?


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

Одной из возможностей этого средства является функция проверок на совместимость (Compatibility Checks). Они нужны, например, в случаях, когда вы настроили интеграцию Hardware Support Manager (HSM) для серверов Dell или HP и хотите проверить оборудование развертываемого сервера на совместимость с ESXi. Это так называемые Hardware Compatibility Checks.

Во время проверок можно использовать кастомный образ ESXi с дополнениями Firmware и Drivers Addon для проверки образов от поддерживаемых вендоров на совместимость с имеющимся у вас оборудованием и установленной версией микрокода. Вот так в vLCM выглядит проверка соответствия для образов ESXi:

На этом скриншоте видно, что текущий уровень компонентов хоста ESXi не соответствует желаемым параметрам в плане версий Firmware аппаратных компонентов. В этом случае есть опция Remediate (кнопка вверху слева), которая позволяет привести хосты ESXi в соответствие, обновив микрокод аппаратных компонентов средствами Hardware Support Manager - и все это прямо из клиента vSphere Client, без сторонних консолей.

vLCM предоставляет также функции автоматической проверки (HCL Automatic Checks), с помощью которых можно автоматически и систематически искать несоответствия уровня firmware на хостах ESXi и сверять их с актуальной онлайн-базой VMware Compatibility Guide (VCG, он же Hardware Compatibility Guide - HCL).

Если вы зайдете в раздел Cluster > Updates, то увидите результат работы автоматического тестирования на совместимость с необходимыми деталями. Пока это доступно только для контроллеров хранилищ vSAN (storage controllers), что является критически важной точкой виртуальной инфраструктуры с точки зрения обновлений (стабильность, производительность).

На скриншоте ниже показаны результаты проверки совместимости в кластере для адаптера Dell HBA330. В данном случае видно, что на всех хостах установлена одинаковая и последняя версия firmware, что и является правильной конфигурацией:

По ссылке "View in HCL" вы сможете увидеть, что данный адаптер с данной версией микрокода действительно поддерживается со стороны VMware vSphere и vSAN.


Таги: VMware, vLCM, Update, Hardware, HCL, ESXi, vSphere

Как установить VMware ESXi 7 на флешку в виртуальной машине VMware Fusion


Если вы на своем Mac решили установить VMware ESXi 7 в виртуальной машине на флешке, то с настройками по умолчанию этого сделать не получится - USB-устройство не обнаружится установщиком и не будет видно в разделе настроек USB & Bluetooth виртуальной машины.

Eric Sloof написал, что перед развертыванием ESXi, чтобы установщик увидел USB-диск, нужно перевести USB Compatibility в режим совместимости с USB 3.0:

После этого можно будет выбрать ваш USB-диск для установки ESXi 7.0:


Таги: VMware, Fusion, VMachines, USB, Storage, ESXi, Troubleshooting, Blogs

Новые возможности фреймворка VMware PowerCLI 12.0


В начале апреля компания VMware обновила свой основной фреймворк для управления виртуальной инфраструктурой с помощью командных сценариев PowerShell до версии PowerCLI 12.0. Напомним, что прошлая версия PowerCLI 11.5 вышла осенью прошлого года.

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

  • Добавлены командлеты для управления хостовой сетью ESXi

Еще в vSphere 6.0 появилась поддержка сетевых стеков хостов ESXi. Она позволяет назначить различные шлюзы для адаптеров VMkernel в целях маршрутизации трафика. Через PowerCLI можно использовать ESXCLI или API для управления этой функциональностью с помощью командлетов Get-VMHostNetworkStack и Set-VMHostNetworkStack. Новый параметр называется "NetworkStack", он был добавлен в командлет New-VMHostNetworkAdapter:

  • Добавлены командлеты для управления решением HCX
  • Появились новые командлеты для управления пространствами имен
  • Командлеты для управления службами Trusted Host Services
  • Командлеты для управления диском гостевой ОС виртуальных машин (VM Guest Disk management)

Теперь раздел гостевой ОС можно замапить на VMDK-диск (пока только для Windows-систем). Для этого потребуется vSphere 7 и VMware Tools не ниже 11-й версии. Эту возможность можно использовать с помощью командлета Get-VMGuestDisk:

  • Новые командлеты для управления VMware Cloud on AWS
  • Новые командлеты для vSAN:
    • Get-VsanFileServiceDomain
    • New-VsanFileServiceDomain
    • Set-VsanFileServiceDomain
    • Remove-VsanFileServiceDomain
    • New-VsanFileServiceIpConfig
    • Get-VsanFileShare
    • New-VsanFileShare
    • Set-VsanFileShare
    • Remove-VsanFileShare
    • New-VsanFileShareNetworkPermission
    • Add-VsanFileServiceOvf
    • Get-VsanFileServiceOvfInfo
  • Новый модуль для управления службами VMware Cloud Services
  • Добавлена поддержка vSphere 7.0
  • Добавлена поддержка vRealize Operations 8.0
  • Обновлена поддержка модулей License и vROps, а также командлета Open-VMConsoleWindow для использования на различных платформах
  • Поддержка Move-VM для сетей opaque networks
  • Добавлена поддержка последних обновлений PowerShell 7.0:

Скачать VMware PowerCLI 12.0 можно по этой ссылке. Полезные ресурсы:


Таги: VMware, PowerCLI, Update, vSAN, PowerShell, ESXi, vSphere, VMachines

Полезная вещь на VMware Labs - vSphere Replication Capacity Planning


На днях на сайте проекта VMware Labs появилась полезная администраторам vSphere штука - утилита vSphere Replication Capacity Planning, позволяющая определить реальное потребление трафика репликации виртуальными машинами и размер передаваемой дельты данных. Это позволяет планировать сетевую инфраструктуру и принимать решения о выделении канала еще до того, как вы включите репликацию для всех своих виртуальных машин.

Утилита Replication Capacity Planning показывает графики, касающиеся объема передачи сетевого трафика LWD (lightweight delta - изменения с момента последней репликации) во времени, а также метрики по размеру дельты в различных временных масштабах - часы, дни, недели и месяцы.

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

Решение vSphere Replication Capacity Planning развертывается как виртуальный модуль (Virtual Appliance), для его работы потребуется VMware ESXi 6.0 или более поздней версии. Скачать его можно по этой ссылке. Документация доступна здесь.


Таги: VMware, vSphere, Replication, Capacity Planning, Storage, Network, ESXi, VMachines, Labs

Ошибка CPU_SUPPORT_ERROR при установке виртуального (Nested) VMware ESXi 7 - что делать?


При развертывании новой версии платформы VMware vSphere 7 в виртуальной машине (вложенные/nested ESXi) на серверах со старыми процессорами вы можете столкнуться с тем, что ваш CPU не поддерживается со стороны платформы:

CPU_SUPPORT ERROR

Такая ситуация, например, произошла у Rajesh Radhakrishnan на сервере HP 380 G7, где он развертывал виртуальный ESXi 7.0 на платформе vSphere 6.0 Update 3:

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

В разделе CPUID Mask нажать ссылку Advanced и далее вбить в регистре eax для Level 1 следующие значения:

  • Для процессоров Intel CPU: 0000:0000:0000:0011:0000:0110:1100:0011
  • Для процессоров AMD CPU: 0000:0000:0110:0000:0000:1111:0001:0000

После этого включайте ВМ, где будет установлен ESXi 7, и проходите до конца установки:

После этого ваш ESXi 7 спокойно загрузится. Затем нужно откатить маскирование функций CPU к исходной чистой конфигурации, удалив значение регистра eax:

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


Таги: VMware, ESXi, Troubleshooting, vSphere, Hardware, CPU, Upgrade

Поддержка протокола синхронизации времени PTP в VMware vSphere 7 - чем он лучше NTP?


Не все в курсе, но одной из новых возможностей обновленной платформы виртуализации VMware vSphere 7 стала поддержка протокола точной синхронизации времени PTP (Precision Time Protocol) для хост-серверов ESXi и виртуальных машин.

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

Abhijeet Deshmukh написал про PTP в vSphere интересную статью, основные моменты которой мы приведем ниже.

Протокол NTP обладает следующими особенностями:

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

Для виртуальных машин у NTP есть следующие особенности:

  • Сервер ESXi имеет встроенную поддержку NTP на уровне стандарта, а также имеет необходимые компоненты для его поддержки в kernel API.
  • NTP работает на порту 123.
  • NTP бесшовно работает для клиентов-виртуальных машин, где ОС поддерживают эту интеграцию.
  • Как правило проблем с NTP не возникает для гостевых ОС, за исключением некоторых ситуаций, когда, например, вы делаете Suspend виртуальной машины.
  • Виртуализация добавляет дополнительные уровни абстракции (например, vNIC), которые потенциально могут повлиять на часы гостевой ОС и переменные синхронизации.

Кстати, о проблеме управления временем в виртуальной инфраструктуре есть отличный документ "Timekeeping in
VMware Virtual Machines
". Кроме того, полезно будет прочитать и вот эту статью.

Давайте теперь посмотрим на особенности протокола PTP (IEEE 1588):

  • PTP работает на уровне точности в микросекундах, для чего используется механизм Hardware time stamping (это специальные сетевые адаптеры с поддержкой PTP).
  • PTP, определенный стандартом IEEE 1588-2008, работает за счет обмена сообщениями мастер-часов и слейв-часов.

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

  • Времена отправки и получения событий Sync и Delay_Request сохраняются как 4 таймстемпа T1-T4.
  • Сообщения Follow_Up и Delay_Response используются для передачи записанных таймстемпов от мастер-часов к слейв, чтобы осуществить коррекцию времени.
  • По окончании передачи слейв-часы имеют все 4 таймстемпа. Это позволяет посчитать смещение от мастера и скорректировать слейв-часы по формуле: Offset = (T2 + T3 – T1 – T4) /2
  • PTP в основном используется для обслуживания финансовых транзакций, передачи на уровне телефонных вышек, подводных систем позиционирования и прочих систем реального времени, где требуется высокая точность времени.
  • PTP поддерживает отказоустойчивость. Если мастер-часы отказывают, то другой мастер принимает на себя его функции, так как находится в постоянном ожидании. Это реализовано средствами алгоритма Best Master Clock (BMC).
  • PTP работает как мультикаст, а значит генерирует дополнительный трафик и требует специальные правила для его перенаправления между сегментами сети.
  • Использует 2 UDP-порта - 319 и 320.
  • В виртуальной машине для поддержки PTP есть специальное устройство precision clock для получения системного времени хоста.
  • В рамках одной сети через PTP все ее виртуальные машины получают точное время.

В итоге можно сделать следующие выводы об использовании протоколов NTP и PTP в виртуальной инфраструктуре:

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

Таги: VMware, vSphere, NTP, Timekeeping, ESXi, Troubleshooting, Blogs

Как проверить, поддерживает ли ваш сервер новую версию VMware ESXi 7 - сценарий PowerCLI


Как все уже знают, VMware vSphere 7 вышла, доступна для скачивания и уже обкатывается многими администраторами виртуальных инфраструктур. Для тех, кто еще не знает, поддерживает ли текущее оборудование новый гипервизор ESXi 7, Florian Grehl сделал специальный сценарий PowerCLI, который позволяет вывести эту информацию для серверов кластера:

Сценарий доступен в репозитории на GitHub. Скрипт автоматически загружает функцию HCL-Check (из GitHub), а также JSON-файл для VMware HCL. В переменной $scope можно установить серверы, которые будут проверены (по умолчанию проверяется все окружение vCenter).

Надо понимать, что если ваш хост не поддерживается для VMware ESXi 7, то имеет смысл проверить его еще раз на всякий случай в реальном VMware HCL.

Если вы получаете вот такое сообщение об ошибке:

.\check_esxi_70_support.ps1 : File .\check_esxi_70_support.ps1 cannot be loaded. The file is not digitally signed. You cannot run this script on the current system. For more information about running scripts and setting execution policy, see about_Execution_Policies at http://go.microsoft.com/fwlink/?LinkID=135170.

Значит нужно в свойствах скрипта разблокировать его:


Таги: VMware, ESXi, Hardware, Blogs, PowerCLI, Update, vSphere

Управление сертификатами в VMware vSphere 7 и режимы оперирования


Как все уже знают, недавно компания VMware выпустила обновление своей флагманской платформы VMware vSphere 7. Одновременно с этим были выпущены новые версии и других продуктов серверной и десктопной линеек.

Сегодня мы поговорим об особенностях управления сертификатами в обновленной инфраструктуре vSphere 7. Во-первых, сертификаты Solution User Certificates были заменены на VMCA Certificates (Intermediate CA), что сильно упростило управление инфраструктурой сертификатов для виртуальной среды:

Второй полезный момент - это интерфейс REST API для обработки сертификатов vCenter Server как часть общей стратегии по управлению всеми аспектами vSphere через API:

Также в vCenter Server и ESXi было сделано много улучшений, чтобы снизить число необходимых сертификатов для случаев, когда вы управляете ими вручную, либо автоматически с помощью центра сертификации VMware Certificate Authority (VMCA), который является частью vCenter.

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

В инфраструктуре vSphere 7 есть 4 способа управления сертификатами:

  • Fully Managed Mode - в этом случае на vCenter есть VMCA с новым корневым сертификатом. Этот режим используется для управления сертификатами внутри кластеров (защита коммуникации между хостами ESXi, а также между ESXi и vCenter). Для этого используются так называемые Machine Certificates. Сертификат VMCA root CA certificate можно загрузить с главной веб-страницы vCenter и импортировать его на свой компьютер для настройки траста. Также можно перегенерировать корневой VMCA-сертификат на базе собственной информации вместо дефолтной (вроде "VMware Engineering" и т.п.).
  • Hybrid Mode - если у вас слишком много пользователей, которые управляют элементами инфраструктуры vSphere, может оказаться непрактичным заставлять всех их импортировать корневые сертификаты на свои машины. Вместо этого вы можете заменить сертификат, который использует vSphere Client, чтобы браузеры принимали его по умолчанию. Однако администраторы vSphere могут по-прежнему хотеть импортировать корневой сертификат VMCA в целях настройки траста с хостами ESXi, чьи управляющие интерфейсы могут иметь сертификаты, подписанные со стороны VMCA. Как правило, команда администраторов не такая большая, поэтому для этого не требуется много усилий.

Надо понимать, что ни в режиме Fully Managed Mode, ни в Hybrid Mode не используются самоподписанные сертификаты. Все эти сертификаты подписаны со стороны VMCA как центра сертификации. Доверяя VMCA, мы безоговорочно доверяем и серверу VMware vCenter, что надо учитывать при планировании защиты виртуальной инфраструктуры.

  • Subordinate CA Mode - в этом режиме VMCA может оперировать как подчиненный центр сертификации, подчиняясь корпоративному CA. В этом режиме vCenter продолжает выполнять функции по автоматизации управления сертификатами как в режиме Fully Managed Mode, за исключением того, что они генерируются на стороне корпоративного центра сертификации. В этом случае надо уделять внимание процессу передачи сертификатов со стороны корпоративного CA на vCenter, так как в это время может произойти их подмена со стороны злоумышленника. Поэтому даже крупные организации, как правило, используют режим Hybrid Mode.
  • Full Custom Mode - в этом случае VMCA не используется для управления сертификатами, а администратор в ручном режиме занимается их генерацией и импортом. Это весьма экзотический сценарий, так как в этом случае придется управлять десятками и даже сотнями сертификатов, в зависимости от размера инфраструктуры. Это рождает большую вероятность человеческой ошибки. Возможно, этот вариант применим для каких-то особо секретных инфраструктур, где доверие людям больше, чем доверие ИТ-системам.

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


Таги: VMware, vSphere, vCenter, Security, Certificates, ESXi

Обновились USB Network Native Driver for ESXi до версии 1.5 и vSphere Software Asset Management Tool до версии 1.1


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

Сейчас в версии 1.5 поддерживаются следующие устройства:

Основная новая возможность - поддержка VMware vSphere 7. Будьте внимательны - для vSphere 7 сделан отдельный дистрибутив. Есть также и отдельные пакеты для vSphere 6.7 и 6.5.

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

Второе небольшое обновление - это новая версия утилиты vSphere Software Asset Management Tool 1.1. С помощью vSAM можно собрать подробную информацию об инсталляции VMware vSphere на вашей площадке, касающуюся лицензий - весь инвентарь и доступные лицензии.

Из новых возможностей - новая таблица Host Inventory Table в генерируемом отчете software asset management, а также косметические исправления текстов. О первой версии утилиты мы писали вот тут.

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


Таги: VMware, Labs, Update, USB, Licensing, Drivers, vSphere, ESXi

Чего больше нет в VMware vSphere 7?


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

1. Больше нет vSphere Web Client на базе Flash

Об этом говорили давно, долго задерживали снятие с производства тяжеловесного vSphere Web Client, но все откладывали из-за несоответствия функциональности клиенту нового поколения vSphere Client на базе технологии HTML5. Теперь в vSphere 7 этот переход окончательно завершен, и старого Web Client больше нет.

Клиент на HTML5 включает в себя не только все старые рабочие процессы Web Client, но и давно получил новые возможности, такие как, например, упрощенная настройка механизма отказоустойчивости vCenter HA (VCHA) и функции обновлений vSphere Update Manager (VUM).

2. Больше нет внешнего PSC (Platform Services Controller)

Как мы уже рассказывали, Embedded PSC - это теперь единственно возможный вариант развертывания. Внешний PSC больше не поддерживается. Встроенный PSC имеет все необходимые сервисы для управления доменом vSphere SSO (подробнее описано в KB 60229).

С помощью утилиты Converge Tool, которая появилась в vSphere 6.7 Update 1, можно смигрировать внешний сервер Platform Services Controller (PSC) на простой в управлении embedded PSC, используя командный интерфейс vCenter Server CLI или графический клиент vSphere Client:

3. Больше нет VMware vCenter for Windows

Как мы уже писали, vSphere 6.7 - это была последняя версия платформы, где для vCenter еще была версия под Windows. Теперь остался только виртуальный модуль vCenter Server Appliance (vCSA) на базе Photon OS. Многие привыкли к сервисам vCenter на базе Windows, теперь придется отвыкать.

VMware рекомендует выполнить 2 основных шага для миграции с vCenter на vCSA:

  • Migration Assistant - консольная утилита, которую нужно выполнить до мастера миграции vCenter. Она выясняет соответствие требованиям к миграции и показывает дальнейшие шаги.
  • Migration Tool - это мастер миграции, который доступен из основного дистрибутива vCenter.

4. Больше нет Update Manager Plugin

На протяжении долгого времени это был плагин для vSphere Web Client. Теперь вместо продукта VMware Update Manager (VUM) в vSphere 7 есть более широкое по функциональности решение VMware Lifecycle Manager.

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

5. Больше нет VNC-сервера в ESXi

Ранее в ESXi был встроенный VNC-сервер, который был убран в последней версии VMware vSphere 7. Раньше можно было соединиться с консолью виртуальной машины с помощью VNC-клиента, добавив в конфигурацию параметр RemoteDisplay.vnc.enable.

Теперь такой возможности больше нет (ей пользовались администраторы систем, не использующих средства VMware). Для соединения с консолью виртуальной машины используйте vSphere Client, хостовый клиент ESXi Host Client или средство VMware Remote Console.

6. Мелочи, которых или уже больше нет или их не рекомендуется использовать (не будет потом)

В эту категорию попали:

  • VMware vSphere 7.0 и протокол TLS Protocol (TLS 1.0 и 1.1 отключены по умолчанию).
  • Нет поддержки резервного копирования на уровне образов (Image-Based Backup) для сервера vCenter.
  • Интерфейс VMKlinux API уже давно безнадежно устарел, вместо него используется архитектура нативных драйверов под vSphere, начиная еще с ESXi 5.5. vmkLinux - это такая прослойка между VMkernel и Linux-драйверами, которая позволяла транслировать команды от ядра (так как VMkernel - это НЕ Linux) к драйверам и обратно. Но теперь нативных партнерских драйверов устройств для ESXi накопилось достаточно, и старая архитектура Linux-драйверов ушла в прошлое.
  • Депрекация поддержки 32-bit Userworld. Ранее партнерам VMware была доступна возможность делать 32-битные драйверы, плагины и другие компоненты в VIB-пакетах. Теперь, начиная со следующих версий vSphere, такой возможности больше не будет.
  • Почти убрана поддержка Integrated Windows Authentication. В этой версии IWA еще работает, но в следующей версии уже не будет. Подробнее в KB 78506.
  • Депрекация аутентификации DCUI Smart Card Authentication. Пользователям со смарт-картами рекомендовано использовать vCenter, PowerCLI или API-вызовы, ну либо логин и пароль по-старинке.
  • Депрекация Core Partition Profile для функциональности Host Profiles. Вместо разделов Coredump Partitions пользователям нужно использовать файлы Coredump Files.

  • Таги: VMware, vSphere, Update, Upgrade, ESXi, vCenter, VMachines

    Улучшения механизма динамической балансировки нагрузки VMware DRS в VMware vSphere 7


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

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

    При этом раньше DRS запускался каждые 5 минут. Теперь же этот механизм запускается каждую минуту, а для генерации рекомендаций используется механизм VM DRS Score (он же VM Hapiness). Это композитная метрика, которая формируется из 10-15 главных метрик машин. Основные метрики из этого числа - Host CPU Cache Cost, VM CPU Ready Time, VM Memory Swapped и Workload Burstiness. Расчеты по памяти теперь основываются на Granted Memory вместо стандартного отклонения по кластеру.

    Мы уже рассказывали, что в настоящее время пользователи стараются не допускать переподписку по памяти для виртуальных машин на хостах (Memory Overcommit), поэтому вместо "Active Memory" DRS 2.0 использует параметр "Granted Memory".

    VM Happiness - это основной KPI, которым руководствуется DRS 2.0 при проведении миграций (то есть главная цель всей цепочки миграций - это улучшить этот показатель). Также эту оценку можно увидеть и в интерфейсе:

    Как видно из картинки, DRS Score квантуется на 5 уровней, к каждому из которых относится определенное количество ВМ в кластере. Соответственно, цель механизма балансировки нагрузки - это увеличить Cluster DRS Score как агрегированный показатель на уровне всего кластера VMware HA / DRS.

    Кстати, на DRS Score влияют не только метрики, касающиеся производительности. Например, на него могут влиять и метрики по заполненности хранилищ, привязанных к хостам ESXi в кластере.

    Надо понимать, что новый DRS позволяет не только выровнять нагрузку, но и защитить отдельные хосты ESXi от внезапных всплесков нагрузки, которые могут привести виртуальные машины к проседанию по производительности. Поэтому главная цель - это держать на высоком уровне Cluster DRS Score и не иметь виртуальных машин с низким VM Hapiness (0-20%):

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

    Если вы нажмете на опцию View all VMs в представлении summary DRS view, то сможете получить детальную информацию о DRS Score каждой из виртуальных машин, а также другие важные метрики:

    Ну и, конечно же, на улучшение общего DRS Score повлияет увеличения числа хостов ESXi в кластере и разгрузка его ресурсов.

    Кстати, ниже приведен небольшой обзор работы в интерфейсе нового DRS:

    Еще одной важной возможностью нового DRS является функция Assignable Hardware. Многие виртуальные машины требуют некоторые аппаратные возможности для поддержания определенного уровня производительности, например, устройств PCIe с поддержкой Dynamic DirectPath I/O или NVIDIA vGPU. В этом случае теперь DRS позволяет назначить профили с поддержкой данных функций для первоначального размещения виртуальных машин в кластере.

    В видео ниже описано более подробно, как это работает:

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

    Этот механизм будет очень важным для таких решений, как vSphere with Kubernetes и vSphere Pod Service, чтобы определенный ярус нагрузок мог получать необходимый уровень ресурсов. Более подробно об этом рассказано в видео ниже:


    Таги: VMware, vSphere, DRS, Update, ESXi, VMachines, Performance

    Что такое физическая и виртуальная память для гипервизора VMware ESXi, и как он с ней работает?


    В блоге VMware vSphere появилась интересная запись о том, как происходит работа с памятью в гипервизоре VMware ESXi. Приведем ее основные моменты ниже.

    Работа виртуальной машины и ее приложений с памятью (RAM) идет через виртуальную память (Virtual Memory), которая транслируется в физическую память сервера (Physical Memory). Память разбита на страницы - это такие блоки, которыми виртуальная память отображается на физическую. Размер этого блока у разных систем бывает разный, но для ESXi стандартный размер страниц равен 4 КБ, а больших страниц - 2 МБ.

    Для трансляции виртуальных адресов в физические используется таблица страниц (Page Table), содержащая записи PTE (Page Table Entries):

    Записи PTE хранят в себе ссылки на реальные физические адреса и некоторые параметры страницы памяти (подробнее можно почитать здесь). Структуры записей PTE могут быть разного размера - это WORD (16 bits/2 bytes), DWORD (32 bits/4 bytes) и QWORD (64 bits/8 bytes). Они адресуют большие блоки адресов в физической памяти, к примеру, DWORD адресует блок адресов 4 килобайта (например, адреса от 4096 до 8191).

    Память читается и передается гостевой системе и приложениям страницами по 4 КБ или 2 МБ - это позволяет читать содержимое ячеек памяти блоками, что существенно ускоряет быстродействие. Естественно, что при таком подходе есть фрагментация памяти - редко когда требуется записать целое число страниц, и часть памяти остается неиспользуемой. При увеличении размера страницы растет и их фрагментация, но увеличивается быстродействие.

    Таблицы страниц (а их может быть несколько) управляются программным или аппаратным компонентом Memory Management Unit (MMU). В случае аппаратного MMU гипервизор передает функции по управлению трансляцией ему, а программный MMU реализован на уровне VMM (Virtual Machine Monitor, часть гипервизора ESXi):

    Важный компонент MMU - это буфер ассоциативной трансляции (Translation Lookaside Buffer, TLB), который представляет собой кэш для MMU. TLB всегда находится как минимум в физической памяти, а для процессоров он часто реализован на уровне самого CPU, чтобы обращение к нему было максимально быстрым. Поэтому обычно время доступа к TLB на процессоре составляет около 10 наносекунд, в то время, как доступ к физической памяти составляет примерно 100 наносекунд. VMware vSphere поддерживает Hardware MMU Offload, то есть передачу функций управления памятью на сторону MMU физического процессора.

    Итак, если от виртуальной машины появился запрос на доступ к виртуальному адресу 0x00004105, то этот адрес разбивается на адрес виртуальной страницы (Virtual page number - 0x0004) и смещение (Offset - 0x105 - область внутри страницы, к которой идет обращение):

    Смещение напрямую передается при доступе к физической странице памяти, а вот тэг виртуальной страницы ищется в TLB. В данном случае в TLB есть запись, что соответствующий этому тэгу адрес физической страницы это 0x0007, соответственно трансляция виртуальной страницы в физическую прошла успешно. Это называется TLB Hit, то есть попадание в кэш.

    Возможна и другая ситуация - при декомпозиции виртуального адреса получаемый тэг 0x0003 отсутствует в TLB. В этом случае происходит поиск страницы в физической памяти по тэгу (страницу номер 3) и уже ее адрес транслируется (0x006). Далее запись с этим тэгом добавляется в TLB (при этом старые записи из кэша вытесняются, если он заполнен):

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

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

    Посмотрим на пример:

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

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


    Таги: VMware, vSphere, ESXi, Memory, Performance, Blogs

    Как изменить MAC-адрес сервера VMware vCenter Server Appliance (vCSA) при развертывании?


    Как знают многие администраторы, во время установки vCenter Server Appliance (vCSA) для управления виртуальной инфраструктурой изменить MAC-адрес управляющего сервера нельзя - он генерируется при развертывании виртуального модуля установщиком и прописывается внутрь конфигурации. Между тем, если вам это все-таки по каким-то причинам требуется, Вильям Лам привел способ, как это сделать.

    Ниже приведена процедура развертывания vCSA с сервера VMware ESXi.

    Во-первых, надо преобразовать OVA-модуль в формат OVF, где можно будет потом изменить настройки. Делается это с помощью утилиты ovftool следующим образом:

    ovftool --allowExtraConfig VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ova VMware-vCenter-Server-Appliance-6.7.0.42000-15132721_OVF10.ovf

    Сначала нам нужно добавить следующую конфигурацию в раздел Network конфигурации виртуального модуля OVF, содержащую нужный нам MAC-адрес:

    <Item>
    <rasd:Address>00:50:56:ab:cd:ef</rasd:Address>
    <rasd:AutomaticAllocation>true</rasd:AutomaticAllocation>
    <rasd:Connection>Network 1</rasd:Connection>
    <rasd:ElementName xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">Ethernet adapter on &quot;Network 1&quot;</rasd:ElementName>
    <rasd:InstanceID xmlns:rasd="http://schemas.dmtf.org/wbem/wscim/1/cim-schema/2/CIM_ResourceAllocationSettingData">3</rasd:InstanceID>
    <rasd:ResourceSubType>vmxnet3</rasd:ResourceSubType>
    <rasd:ResourceType>10</rasd:ResourceType>
    </Item>

    Далее изменяем скрипт VCSAStaticMACAddress.sh на сервере ESXi, чтобы добавить туда нужные параметры вашего vCSA и начать его развертывание в вашей виртуальной среде. Для этого его нужно выполнить с параметром --injectOvfEnv, про который написано вот тут. Он позволяет внедрить свойства OVF в виртуальный модуль vCSA при его включении.

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

    https://[адрес VCSA]:5480

    В итоге вы должны увидеть, что в настройках модуля vCSA вы получили нужный вам MAC-адрес:

    Если вы хотите пропустить стадию конфигурации сетевых настроек (IP-адрес и прочее) при исполнении скрипта, нужно выставить переменную VCSA_STAGE1ANDSTAGE2 в значение false. Тогда после развертывания модуля vCSA нужно будет закончить его конфигурацию по ссылке:

    https://[адрес VCSA]:5480

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


    Таги: VMware, vCSA, Network, ESXi, Blogs

    <<   <    1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30    >   >>
Интересное:





Зал Славы Рекламодателя
Ближайшие события в области виртуализации:

Быстрый переход:
VMware Broadcom Offtopic Microsoft Veeam Cloud StarWind VMachines NAKIVO vStack Gartner Vinchin Nakivo IT-Grad Teradici VeeamON VMworld PowerCLI Citrix VSAN GDPR 5nine Hardware Nutanix vSphere RVTools Enterprise Security Code Cisco vGate SDRS Parallels IaaS HP VMFS VM Guru Oracle Red Hat Azure KVM VeeamOn 1cloud DevOps Docker Storage NVIDIA Partnership Dell Virtual SAN Virtualization VMTurbo vRealize VirtualBox Symantec Softline EMC Login VSI Xen Amazon NetApp VDI Linux Hyper-V IBM Google VSI Security Windows vCenter Webinar View VKernel Events Windows 7 Caravan Apple TPS Hyper9 Nicira Blogs IDC Sun VMC Xtravirt Novell IntelVT Сравнение VirtualIron XenServer CitrixXen ESXi ESX ThinApp Books P2V vSAN Private AI VCPP VCF Workstation Labs Backup Explore vDefend Data Protection ONE Tanzu AI Intel Live Recovery VCP V2V HCX Aria NSX DPU Update EUC Avi Community Skyline Host Client Chargeback Horizon SASE Workspace ONE Networking Ransomware Tools Performance Lifecycle Network AWS API USB SDDC Fusion Whitepaper SD-WAN Mobile VMUG SRM ARM HCI Converter Photon OS Operations VEBA App Volumes Certification VMConAWS Workspace Imager SplinterDB DRS SAN vMotion Open Source iSCSI Partners HA Monterey Kubernetes vForum Learning vRNI UAG Support Log Insight AMD vCSA NSX-T Graphics NVMe HCIBench SureBackup Carbon Black vCloud Обучение Web Client vExpert OpenStack UEM CPU PKS vROPs Stencils Bug VTL Forum Video Update Manager VVols DR Cache Storage DRS Visio Manager Virtual Appliance PowerShell LSFS Client Datacenter Agent esxtop Book Photon Cloud Computing SSD Comparison Blast Encryption Nested XenDesktop VSA vNetwork SSO VMDK Appliance VUM HoL Automation Replication Desktop Fault Tolerance Vanguard SaaS Connector Event Free SQL Sponsorship Finance FT Containers XenApp Snapshots vGPU Auto Deploy SMB RDM Mirage XenClient MP iOS SC VMM VDP PCoIP RHEV vMA Award Licensing Logs Server Demo vCHS Calculator Бесплатно Beta Exchange MAP DaaS Hybrid Monitoring VPLEX UCS GPU SDK Poster VSPP Receiver VDI-in-a-Box Deduplication Reporter vShield ACE Go nworks iPad XCP Data Recovery Documentation Sizing Pricing VMotion Snapshot FlexPod VMsafe Enteprise Monitor vStorage Essentials Live Migration SCVMM TCO Studio AMD-V KB VirtualCenter NFS ThinPrint Memory SIOC Troubleshooting Stretched Bugs Director ESA Android Python Upgrade ML Hub Guardrails CLI Driver Foundation HPC Orchestrator Optimization SVMotion Diagram Ports Plugin Helpdesk VIC VDS Migration Air DPM Flex Mac SSH VAAI Heartbeat MSCS Composer
Полезные постеры:

Постер VMware vSphere PowerCLI 10

Постер VMware Cloud Foundation 4 Architecture

Постер VMware vCloud Networking

Постер VMware Cloud on AWS Logical Design Poster for Workload Mobility

Постер Azure VMware Solution Logical Design

Постер Google Cloud VMware Engine Logical Design

Постер Multi-Cloud Application Mobility

Постер VMware NSX (референсный):

Постер VMware vCloud SDK:

Постер VMware vCloud Suite:

Управление памятью в VMware vSphere 5:

Как работает кластер VMware High Availability:

Постер VMware vSphere 5.5 ESXTOP (обзорный):

 

Популярные статьи:
Как установить VMware ESXi. Инструкция по установке сервера ESXi 4 из состава vSphere.

Включение поддержки технологии Intel VT на ноутбуках Sony VAIO, Toshiba, Lenovo и других.

Типы виртуальных дисков vmdk виртуальных машин на VMware vSphere / ESX 4.

Как работают виртуальные сети VLAN на хостах VMware ESX / ESXi.

Как настроить запуск виртуальных машин VMware Workstation и Server при старте Windows

Сравнение Oracle VirtualBox и VMware Workstation.

Что такое и как работает виртуальная машина Windows XP Mode в Windows 7.

Диски RDM (Raw Device Mapping) для виртуальных машин VMware vSphere и серверов ESX.

Работа с дисками виртуальных машин VMware.

Где скачать последнюю версию VMware Tools для виртуальных машин на VMware ESXi.

Подключение локальных SATA-дисков сервера VMware ESXi в качестве хранилищ RDM для виртуальных машин.

Как перенести виртуальную машину VirtualBox в VMware Workstation и обратно

Инфраструктура виртуальных десктопов VMware View 3 (VDI)

Как использовать возможности VMware vSphere Management Assistant (vMA).

Бесплатные утилиты для виртуальных машин на базе VMware ESX / ESXi.

Интервью:

Alessandro Perilli
virtualization.info
Основатель

Ратмир Тимашев
Veeam Software
Президент


Полезные ресурсы:

Последние 100 утилит VMware Labs

Новые возможности VMware vSphere 8.0 Update 1

Новые возможности VMware vSAN 8.0 Update 1

Новые документы от VMware

Новые технологии и продукты на VMware Explore 2022

Анонсы VMware весной 2021 года

Новые технологии и продукты на VMware VMworld 2021

Новые технологии и продукты на VMware VMworld 2020

Новые технологии и продукты на VMware VMworld Europe 2019

Новые технологии и продукты на VMware VMworld US 2019

Новые технологии и продукты на VMware VMworld 2019

Новые технологии и продукты на VMware VMworld 2018

Новые технологии и продукты на VMware VMworld 2017



Copyright VM Guru 2006 - 2025, Александр Самойленко. Правила перепечатки материалов.
vExpert Badge