Недавно мы писали о полезном документе для администраторов VMware vSphere 6.5 - Performance Best Practices for VMware vSphere 6.5. Этот документ обязательно надо прочитать, там много всего полезного и интересного.

Например, там есть немного про улучшение команды esxtop, показывающей производительность хоста и виртуальных машин в различных аспектах. Теперь там добавилась метрика Power Management, где можно в реальном времени наблюдать за актуальной частотой процессора. Эта информация теперь отображается в колонке %A/MPERF.

Чтобы добавить ее, после запуска esxtop нажмите клавишу <p> и затем клавишу <f> для добавления колонки.

Вы увидите значения, некоторые из которых больше 100. Например, для процессора 2 и 4 на картинке выше значения равны 150. При этом это процессор Xeon E5-2699 v3 2.3 ГГц с функцией разгона частоты Turbo Boost до 3.6 ГГц. Значение 150 означает, что в данный момент процессор работает на частоте 2.3*1.5 = 3.45 ГГц, то есть почти на пределе.

Продолжаем информировать вас о выпусках обновлений и заплаток уязвимостей Meltdown и Spectre для виртуальной инфраструктуры VMware vSphere. Напомним наши прошлые посты:

• Как отслеживать производительность хостов VMware ESXi после патчей Meltdown и Spectre с помощью VMware vSphere Operations Manager
• Вышел VMware vCenter Server Appliance 6.5 Update 1f - исправлена уязвимость Meltdown и Spectre (частично)
• Производительность хост-серверов VMware ESXi и других платформ после наката патчей для Meltdown и Spectre
• Для VMware vSphere, Workstation и Fusion пофикшена уязвимость Spectre
• Скрипт для проверки виртуальной инфраструктуры VMware vSphere на подверженность уязвимости Spectre

На днях наш читатель Стас прислал новость о том, что VMware выпустила обновления, закрывающие уязвимость Spectre, на этот раз для ключевых компонентов виртуальной инфраструктуры - серверов vCenter и ESXi. Таким образом, согласно VMware Security Advisory VMSA-2018-0004.3, теперь от уязвимости Spectre защищены все основные продукты VMware трех последних поколений:

Начнем с обновлений для vCenter. Тут были выпущены следующие апдейты:

• VMware vCenter Server 5.5 Update 3h (Release notes, скачать)
• VMware vCenter Server 6.0 Update 3e (Release notes, скачать)
• VMware vCenter Server 6.5 Update 1g (Release notes, скачать)

Для серверов VMware ESXi были выпущены следующие патчи:

• ESXi550-201803001 (ESXi550-201803401-BG и ESXi550-201803402-BG)

• ESXi600-201803001 (ESXi600-201803401-BG и ESXi600-201803402-BG)

• ESXi650-201803001 (ESXi650-201803401-BG и ESXi650-201803402-BG)

Чтобы скачать эти обновления для ESXi, нужно пойти VMware Patch Portal и поискать там обновления для соответствующей версии ESXi.

Кроме наката патчей гипервизора VMware ESXi, вам также придется обновить микрокод серверов. Более подробная информация об этом приведена в KB 52085.

Помните, что порядок наката обновлений безопасности таков:

1. Накатываем обновления vCenter.

2. Обновляем ПО гипервизора на серверах VMware ESXi - накатываем апдейты, заканчивающиеся на 01-BG (позволяет гостевым ОС использовать новый механизм speculative-execution control), одновременно с этим обновляем и микрокод серверов (апдейты, заканчивающиеся на 02-BG), которое применяется в процессе загрузки ESXi. Оба патча накатываются в рамках одного профиля.

Многие из вас иногда хотят получить так называемый "Support Bundle", содержащий лог-файлы, диагностическую информацию и метрики производительности, который помогает решать проблемы в инфраструктуры VMware vSphere. В первую очередь, этот бандл нужен для предоставления службе технической поддержки VMware GSS (Global Support Services) информации о конфигурации виртуальной среды, чтобы она могла решать возникающие у клиентов проблемы в рамках обращений (тикетов) в техподдержку.

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

Давайте рассмотрим основные способы получения support bundle как для серверов VMware vCenter (для Windows или виртуального модуля vCenter Server Appliance, vCSA), так и для серверов VMware ESXi. Кстати, надо учитывать, что после экспорта бандла с логами результирующий файл будет размером 30-300 МБ в зависимости от того, что вы туда включите, а также как давно и интенсивно менялась конфигурация виртуальной среды.

Получение Support Bundle для серверов vCenter

Самый простой способ получить саппорт бандл - это выгрузить его с помощью vSphere Web Client. Для этого нужно выбрать сервер vCenter в иерархии инвентори и выбрать пункт Export System Logs (работает как для обычного vCenter, так и для vCSA):

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

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

https://<ip vcsa>/appliance/support-bundle

И далее ввести логин и пароль root от виртуального модуля vCSA.

После этого support bundle будет сгенерирован и загружен через ваш браузер.

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

curl -k -u root -o support-bundle.tar.gz -O https://<ip vcsa>/applmgmt/support-bundle

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

tar -zxvf support-bundle.tar.gz

Также Support Bundle можно получить с помощью PowerCLI. Для этого нужно соединиться с сервером vCenter:

Connect-VIServer -Server HostnameOrIPAddress

И далее использовать следующую команду:

Get-Log -Bundle -DestinationPath c:\Storage\Location\

Более подробная информация об этом приведена в KB 1027932. Там же, кстати, есть информация и о том, как искать в файлах логов с помощью PowerCLI:

Get-VMHost HostNameOrIP | Get-Log LogName | Select -expand Entries | Select-String SearchTerm | More

Здесь SearchTerm - это строка поиска, а LogName - это один из следующих логов:

• hostd
• vpxa
• messages
• vmkernel
• vmksummary
• vmkwarning

Получение Support Bundle для серверов ESXi

По аналогии с получением бандла для сервера VMware vCenter или vCSA, в vSphere Client можно выбрать сервер VMware ESXi и выбрать для него пункт "Export System Logs":

Также можно сгенерировать Support Bundle через тонкий клиент для управления серверами VMware ESXi - Embedded Host Client (он же - просто веб-интерфейс для управления хостами ESXi). Он доступен при соединении с хостом ESXi по ссылке:

https://<ip esxi>/ui

Для генерации саппорт бандла нужно выбрать пункт "Generate support bundle" из контекстного меню хоста:

Помимо этого, его можно сгенерировать и в консоли ESXi. Для этого используется команда vm-support без параметров (подробнее об этом написано в KB 1010705). Чтобы получить Support Bundle нужно в консоли ESXi выполнить следующую команду:

# vm-support

Надо отметить, что у утилиты есть множество разных параметров:

Аналогично получению бандла для vCenter, через PowerCLI можно получить и бандл для хоста ESXi. Соединяемся с хостом, забираем бандл и складываем его в нужную папку:

Get-VMHost HostNameOrIP | Get-Log -Bundle -DestinationPath c:\Storage\Location\

Для тех, кто хочет узнать, что же находится внутри Support Bundle, мы рекомендуем статью "What's Inside an ESXi vm-support Bundle?".

Если вы зайдете на страницу поддерживаемых устройств ввода-вывода (I/O Devices) в списке VMware Hardware Compatibility List (HCL), то в правой колонке увидите там следующие параметры:

• VID (Vendor ID)
• DID (Device ID)
• SVID (Sub-Vendor ID)
• SSID (Sub-Device ID)

Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.

Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):

vmkchdev -l | grep vmnic

Далее вы увидите подобный вывод:

[dpasek@esx01:~] vmkchdev -l | grep vmnic

0000:02:00.0 14e4:1657 103c:22be vmkernel vmnic0

0000:02:00.1 14e4:1657 103c:22be vmkernel vmnic1

0000:02:00.2 14e4:1657 103c:22be vmkernel vmnic2

0000:02:00.3 14e4:1657 103c:22be vmkernel vmnic3

0000:05:00.0 14e4:168e 103c:339d vmkernel vmnic4

0000:05:00.1 14e4:168e 103c:339d vmkernel vmnic5

0000:88:00.0 14e4:168e 103c:339d vmkernel vmnic6

0000:88:00.1 14e4:168e 103c:339d vmkernel vmnic7

Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:

• VID = 14e4
• DID = 1657
• SVID = 103c
• SSID = 22be

После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.

Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.

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

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

Приведем данный список ниже:

Бизнес-задачи и проблемы

• Какие основные задачи стоят при внедрении?
• Какие проблемы заказчика предполагается решить?

Варианты использования платформы

• Какие варианты использования инфраструктуры VMware предполагает сам заказчик?

Требования/Ограничения/Допущения

• Каковы основные требования, какие ограничения учесть, о какие допущениях и неочевидных моментах нужно проинформировать заказчика.

Риски

• Какие риски внедрения решения (например, простои при миграции) и каковы способы их минимизации? Есть ли специфические задачи, тесты и процедуры, которым нужно следовать в таком случае.

A. Управление виртуальным датацентром

Решения в области логической архитектуры

• Общий объем объединяемых в пул ресурсов (вычислительные мощности, сети и хранилища).
• Какие сервисы будет предоставлять инфраструктура.
• Необходимый уровень доступности для систем управления платформой виртуализации.
• Интеграция со сторонними решениями: IT Service Management, Infrastructure Management systems, Enterprise services (DNS, LDAP, NTP, PKI, Syslog, SNMP Traps), сбор данных агентами систем различных вендоров.
• Необходимы ли расширенные операции, не предоставляемые из коробки?
• Механизмы защиты рабочих нагрузок гипервизора (vMotion, HA и другое).
• Механизмы балансировки нагрузки на гипервизор (DRS).

Решения в области физической инфраструктуры

• Гипервизор: версии ESXi.
• Нужен ли отдельный кластер управления?
• Серверы vCenter в режиме Standalone или Linked-Mode?
• Версия vCenter Server и тип установки (под Windows или в виде виртуального модуля).
• База данных vCenter Server - встроенная или внешняя?
• Механизмы защиты vCenter Server.
• Дизайн инфраструктуры Platform Services Controller (PSC). Будет ли один домен SSO?
• Нужна ли инфраструктура шифрования (PKI)? Какие требования к SSL?
• Какие компоненты vSphere будут использоваться?
• Нужна ли функциональность Host profiles?
• Вопросы управления обновлениями ESXi, версиями VM Hardware и версиями VMware Tools.
• Интеграция с антивирусами и решениями vShield/NSX.
• Нужен ли пакет vRealize Suite для расширенных операций и управления частным облаком?
• Нужен ли продукт vRealize Orchestrator для управления рабочими процессами операций? Нужен ли PowerCLI для сценариев автоматизации?
• Нужно ли интегрировать виртуальную инфраструктуру с другими средствами управления (Enterprise Management)?
• Automated vendor support mechanisms? How will VMware Skyline be used?
• Нужно ли организовывать интеграцию с системами Service Desk или Change Management?
• Каковы требования к механизмам vSphere HA и vSphere DRS?
• Если будет использоваться HCI (Hyper-Converged Infrastructure), то какие решения будут использоваться для управления, и как это будет совместимо с vSphere?
• Вопросы интеграции со службами DNS и NTP.
• Ролевая модель доступа (Role Based Access Control) и интеграция с LDAP.
• Какой интерфейс vCenter Server будет использоваться для администрирования и ежедневных операций (vSphere Client / Web Client).
• Модель лицензирования vCenter.
• Вопросы лицензирования стороннего ПО в виртуальных машинах (на хост, на виртуальный процессор vCPU и т.п.).

B. Вычислительные ресурсы

Решения в области логической архитектуры

• Традиционная архитектура, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с хранилищами).
• Минимальное число хостов в кластере.
• Тип сайзинга хостов в кластерах: вертикальный (Scale Up) или горизонтальный (Scale Out)?
• Гомогенные или гетерогенные узлы?
• Число физических процессоров на хост.
• Резервирование уровня хостов в рамках доменов отказа (Failure Domains).
• Необходимая емкость по CPU.
• Необходимая емкость по RAM.

Решения в области физической инфраструктуры

• Вендор серверов.
• Тип процессоров серверов.
• Фичи CPU: VT-x, Hyper-threading, Turbo Boost, включена ли NUMA?
• Конфигурация серверного оборудования.
• Число сокетов CPU на узел.
• Модель процессора, частота и число ядер.
• Нужен ли GPU?
• Физическое размещение хостов.
• Тип размещения: Single Rack или Multi-Rack с шарингом ресурсов?
• Требования к доступности кластеров.
• Нужно ли обеспечить согласованность доступности хостов с доступностью хранилищ.
• Будущее расширение вычислительных ресурсов.

C. Хранилища

Решения в области логической архитектуры

• Традиционные хранилища, технология Server-Side Flash Cache Acceleration, конвергентная или гиперконвергентная инфраструктура (связано с вычислительными ресурсами).
• Блочные или IP-хранилища?
• Средства автоматизированного управления хранилищами.
• Допустимо ли использование RDM?
• Метод загрузки хоста ESXi - с локального диска (DAS), LUN или PXE.
• Толстые или тонкие диски для виртуальных машин?
• Необходимые ресурсы хранения.
• Репликация хранилищ.

Решения в области физической инфраструктуры

• Вендор систем хранения.
• Расчет используемой емкости хранилищ с учетом пулов хранения, затрат на репликацию и бэкап. Каковы численные требования к емкости и производительности хранилищ?
• Число дисков SSD и HDD в каждой из систем хранения.
• Использование дедупликации, сжатия данных, технологии Erasure Coding и Storage APIs. Нужно ли держать процент хранилищ всегда свободным?
• Какой активный Working Set (рабочий объем данных) необходим?
• Трешхолды для автоматизированного ярусного хранения данных (разнесения по ярусам).
• Использование шифрованных дисков и сервер KMS.
• Сеть хранения данных и ее организация.
• Механизм загрузки хстов ESXi.
• Технологии VM DirectPath I/O и SR-IOV.
• Число датасторов на кластер.
• Будут ли использоваться DRS и SIOC?
• Будут ли применяться VMDK shares на уровне виртуальных дисков?
• Будет ли использоваться технология VAAI?
• Использование VASA и профилей хранилищ (storage profiles).
• Будут ли использоваться синхронные или асинхронные DR-решения?
• Планирование расширения хранилищ.

D. Сетевая инфраструктура

Решения в области логической архитектуры

• Технология Legacy 3-Tier Switch, Collapsed Core или Clos-type Leaf/Spine?
• Кластеризованные физические или отдельные коммутаторы EoR/ToR?
• Растянутые логические VLAN или на уровне стойки?
• Трафик будет функционально разделяться на уровне виртуальных коммутаторов или отдельных VLAN?
• Будут ли использоваться Jumbo Frames?
• Требования Quality of Service (QoS).
• Балансировка нагрузки в сети (Load Balancing).
• Версия протокола IP.
• Соединения Inter-Data Center, включая RTT.
• Требуемая емкость и пропускная способность сети.
• Какие ВМ разрешены - с одним или несколькими vNIC?

Решения в области физической инфраструктуры

• Выбор вендора решения Clos-type Leaf/Spine для больших инсталляций. Либо использование архитектуры Core/Agg/Dist/Access switch.
• Фабрика коммутаторов типа Blocking или non-blocking?
• Если blocking, какое уровень переподписки (over-subscription ratio)?
• Каков путь трафика типа North/South и East/West?
• Где находятся шлюзы Layer 3 для каждой из подсетей?
• Требования к динамической маршрутизации (Dynamic Routing)?
• Нужен ли мультикаст?
• Будут ли использоваться End-to-End Jumbo Frames?
• Интерфейсы хостов ESXi: 1GbE и/или 10GbE? Сколько их будет на каждом хосте?
• Интерфейсы на хостах - LAG или unbonded?
• Слой управления для KVM и iLO/iDRAC/IPMI.
• Производительность физической сети LAN.
• Матрица связности хостов по сети передачи данных.
• Нужно ли Metro Ethernet между датацентрами?
• Использование QoS, Network Control и vSphere Network I/O Control.
• Будет ли использоваться Edge QoS или End-to-End QoS?
• Система vSphere NIOC и User-Defined Network Resource Pools.
• vMotion через несколько физических адаптеров одновременно.
• Использование VLAN Pruning.
• Использование Spanning Tree.
• Технологии VM DirectPath I/O и SR-IOV.
• Будет ли включена TCP Offload?
• Будут ли использованы стандартные vSwitch (VSS) или распределенные Distributed Switch (VDS).
• Разные vSwitches на кластер или общие?
• Использование технологий Teaming и Load Balancing.
• Порты VMkernel.
• Группы портов для виртуальных машин.
• Нужно ли решение VMware NSX-v?
• Планирование расширения сети по числу портов.

E. Защита данных

Решения в области логической архитектуры

• Частота резервного копирования большинства ВМ.
• Настройки бэкапов уровня Application Consistent и Database Consistent.
• Требования ко времени восстановления.
• Физическое разделение актуальных данных и бэкапов.
• Необходимые решения для бэкапа.
• Требования к производительности процесса резервного копирования.

Решения в области физической инфраструктуры

• Будет ли использоваться решение на базе VADP (например, Veeam Backup and Replication).
• Критерии для выбора решения по бэкапу.
• Требования к механизму резервного копирования и восстановления.
• Снапшоты уровня ВМ.
• Нужна ли асинхронная репликация снапшотов ВМ в удаленный кластер или публичное облако.
• Частота резервного копирования.
• Политика хранения резервных копий.
• Выделяемые емкости под хранение бэкапов и производительность процесса.
• Быстрое восстановление средств управления кластером на хосте ESXi.
• Рост объема хранения бэкапов и ресурсы для его обслуживания.

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

Решения в области логической архитектуры

• Стандартные размеры ВМ (по уровням настроек - виртуальный диск, память, сеть, опции).
• Какие механизмы для CPU и RAM будут использоваться (например, Memory Ballooning)?
• Размещение файлов ВМ.
• Стандартизация гостевых ОС.
• Выбор между 64 и 32-битными системами.
• Использование шаблонов.

Решения в области физической инфраструктуры

• Стандартные размеры виртуальных машин и ресурсы для них.
• Планирование виртуальных сервисов vApps и пулов ресурсов.
• Размещение виртуальных машин на общих хранилищах.
• Стандартные настройки виртуальных дисков машин.
• Будут ли использоваться тонкие диски?
• Допустимы ли аппаратные снапшоты на уровне хранилищ или снапшоты vSphere?
• Будет ли включен Changed Block Tracking (CBT)?
• 32/64-битные версии гостевых систем.
• Адаптеры vSCSI.
• Виртуальные сетевые адаптеры vNIC.
• Версия виртуального аппаратного обеспечения (VM Hardware).
• Будут ли установлены VMware Tools и какой версии?
• Прочие стандартные настройки ВМ.
• Какие шаблоны ВМ будут использоваться?
• Настройки репозиториев шаблонов ВМ.
• Предложения по работе виртуальных машин с приложениями уровней Mission-Critical/Business-Critical.

G. Безопасность

Решения в области логической архитектуры

• Зоны и трасты.
• Нужна ли Defence-in-Depth?
• Будет ли решение мультивендоным?
• Физическое разделение сегментов сети.
• Стандарты, которые нужно соблюсти.
• Требования к защите инфраструктуры виртуализации и виртуальным машинам.
• Необходимый объем защиты сетевой инфраструктуры.

Решения в области физической инфраструктуры

• Физическое и виртуальное зонирование сетей.
• Сетевые экраны уровня приложений и уровня сетей.
• Системы IDS и IPS.
• SSL и сети IP-Sec VPN.
• Комплексная защита от сетевых угроз (Unified Threat Management)?
• Выбор вендора в сфере решений ИТ-безопасности.
• Нужно ли решение VMware NSX-v/T?
• Защита конечных устройств и выбор антивирусов.
• Производительность решений для сеNetwork Security Performance?
• Системы Security Information & Event Management (SIEM).
• Будет ли использоваться инфраструктура шифрования (Public Key Infrastructure, PKI)?
• Будет ли использоваться технология vSphere Cluster security? STIG?
• Технологии защиты хоста ESXi.
• Технологии защиты сетевого взаимодействия.
• Технологии защиты хранилищ.
• Технологии защиты резервных копий.
• Технологии защиты виртуальных машин.
• Будет ли будущее расширение инфраструктуры и какие дополнительные средства могут понадобиться?

H. Непрерывность бизнеса / восстановление после аварий (BC/DR)

Решения в области логической архитектуры

• Какие механизмы защиты будут использоваться?
• Ручные или автоматические сценарии восстановления? Регламент ручных действий.
• Политики RPO, RTO, WRT и MTD для приложений различной степени критичности (Mission-Critical, Business-Critical и Non-Critical).
• Как использовать глобальные балансировщики (Global Site Load Balancers).
• Параметры DNS TTL для клиентов.

Решения в области физической инфраструктуры

• Нужны ли решения по катастрофоустойчивости?
• Нужен ли продукт VMware SRM или Veeam Availability Suite?
• Нужно ли решение GSLB?
• Использование внутренних и внешних DNS-серверов.
• Уровень катастрофоустойчивости - нужна ли синхронная репликация на географически удаленные кластеры?
• Репликация на несколько площадок, репликация баз данных и Message Queue clustering/replication.

На днях мы писали о том, что компания VMware выпустила обновления VMware vCenter и ESXi, закрывающие потенциальную угрозу безопасности Spectre (она же Hypervisor-Assisted Guest Mitigation - CVE-2017-5715), которая недавно была обнаружена в процессорах Intel. Для закрытия уязвимости нужно обновить не только серверы ESXi и vCenter, но и микрокод (BIOS/Firmware) серверов (более подробная информация также приведена в KB 52085).

На днях наш читатель Сергей прислал ссылку на скрипт от Вильяма Лама, который позволяет провести проверку компонентов виртуальной инфраструктуры VMware vSphere на данную уязвимость. Этот PowerCLI-скрипт содержит две функции:

• Verify-ESXiMicrocodePatchAndVM
• Verify-ESXiMicrocodePatch

Первая функция позволяет проверить хосты ESXi и виртуальные машины и сгенерировать отчет в разрезе виртуальных машин. Если в колонке Affected стоит значение False - значит обновления и микрокода сервера, и хоста ESXi были применены, а сами ВМ и хост-сервер не подвержены уязвимости Spectre.

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

Функция Verify-ESXiMicrocodePatchAndVM может быть запущена тремя способами:

• Без параметров - проверяется все окружение VMware vSphere и все виртуальные машины в нем.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты и ВМ.
• С параметром - VMName - проверяется только конкретная ВМ и ее хост, соответственно.

У функции Verify-ESXiMicrocodePatch также есть три способа вызова:

• Без параметров - проверяются все хост-сервера в инфраструктуре vCenter.
• С параметром - ClusterName - проверяется конкретный кластер и всего его хосты.
• С параметром - VMHostName - проверяется конкретный хост-сервер ESXi.

Скачать этот PowerCLI-сценарий можно по этой ссылке: VerifyESXiMicrocodePatch.ps1.

Кстати говоря, этот скрипт был добавлен в полезный скрипт vCheck, который перед Новым годом обновился до версии 6.25, скачать его можно вот тут - https://github.com/alanrenouf/vCheck-vSphere.

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

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

Исправления для серверов VMware vCenter можно скачать по этим ссылкам:

• VMware vCenter Server 5.5 Update 3g - Release Notes - Загрузить
• VMware vCenter Server 6.0 U3d - Release Notes - Загрузить
• VMware vCenter Server 6.5 U1e - Release Notes - Загрузить

Вы можете скачать как установочный образ:

так и патч к vCenter с VMware Patch Portal (ищите обновление от 9 января):

Для серверов VMware ESXi надо пойти на VMware Patch Portal и загрузить оттуда обновление ESXi650-201801401-BG / ESXi650-201801402-BG. (номер билда 7526125). Подробная информация об обновлении приведена в KB 2151099.

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

• VMware Workstation 14.1.1 Pro for Linux - Загрузить
• VMware Workstation 14.1.1 Pro for Windows - Загрузить
• VMware Fusion 10.1.1 (для Intel-based Macs) - Загрузить
• VMware Fusion 8.5.10 (для Mac OS X) - Загрузить

Спасибо нашему читателю Стасу за новость об этих исправлениях.

На днях компания VMware выпустила пакет обновления к VMware ESXi 6.5 Update 1, именуемый как Patch 02, добавляющий несколько новых возможностей к решению для создания отказоустойчивых кластеров хранилищ VMware vSAN. Более подробно об этом патче написано в KB 51891.

Новое обновление ESXi включaет в себя следующие фичи vSAN:

• Продукт vSAN Support Insight - эта фича показана в видео выше. Она позволяет пользователям, участвующим в программе CEIP (Customer Experience Improvement Program) получить доступ к расширенной аналитике vSAN в целях решения проблем. Средствами Support Insight сотрудники техподдержки VMware могут исследовать окружения пользователей, понимать их конфигурацию, статус исполнения, производительность и прочие детали в масштабе времени близком к реальному. Документация по этой фиче доступна тут.

Выглядит это примерно следующим образом:

• Технология Adaptive resynchronization – функция Adaptive Resync адаптивно изменяет долю полосы пропускания, выделенную для канала ресинхронизации Resync I/O, чтобы минимизировать негативное влияние на работу клиентского канала ввода-вывода. За счет этого в периоды меньшей загрузки (выходные) канал для ресинхронизации используется больше, а во время часов пик - меньше.
• Поддержка доступа по нескольким путям для SAS-систем. Теперь из коробки поддерживается multipathing для SAS c запасными путями. Пример такого хранилища - HPE Synergy.

Скачать VMware ESXi 6.5 Patch 2 можно c VMware Patch Portal по этой ссылке (надо выбрать релиз ESXi650-201712001 с номером билда 7388607).

Более детальная информация об обновлении приведена тут.

Также вышел и vCenter Server 6.5 Update 1d - там ничего нового, кроме обновлений отдельных компонентов.

На днях компания VMware выпустила очередное обновление средства интеграции с гостевыми ОС виртуальных машин - VMware Tools 10.2.0. Напомним, что о прошлом релизе тулзов (10.1) мы писали вот тут. Кстати, у нас в последнее время было несколько интересных статей на тему этого пакета, например - раз, два и три.

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

• Офлайн бандл VMware Tools VIB-пакета: его можно установить на vSphere 5.5.x, 6.0.x and 6.5.x через vSphere Update Manager.
• Поддерживаемые ОС:
  • windows.iso - поддерживает Windows Vista и более поздние.
  • linux.iso - поддерживает Red Hat Enterprise Linux (RHEL) 5 и более поздние, SUSE Linux Enterprise Server (SLES) 11 и новее, Ubuntu 10.04 и новее. Также поддерживаются дистрибутивы Linux - c glibc версии 2.5 и новее.
  • darwin.iso - поддерживает Mac OS X 10.11 и новее.
  • solaris.iso - для гостевых ОС Solaris.
• Улучшенное управление жизненным циклом VMware Tools: теперь Microsoft System Center Configuration Manager (SCCM) можно использовать для распространения и обновления VMware Tools. Для получения детальной информации смотрите статью Deploying VMware Tools using SCCM.
• Убрана поддержка FreeBSD. Это сделано для того, чтобы перенести ее в пакет open-vm-tools. Подробнее об этом читайте у нас тут.
• Поддержка ASLR (Address space layout randomization).
• Пофикшены ошибки. Для этого смотрите секцию Resolved Issues в Release notes.

Напомним, что для VMware Tools, начиная с версии 10.1, доступна подробная документация. Обновлять VMware Tools лучше через VMware Update Manager. Кстати, в онлайн-репозитории VMware версии 10.2 на момент написания заметки еще не было, но скоро он должен обновиться.

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

Давайте взглянем на эволюцию максимумов VMware vSphere в таблицах ниже, где отображены параметры версии 5.5, 6.0 и 6.5:

Максимумы виртуальных машин

Максимумы вычислительных мощностей VMware ESXi

Максимумы хранилищ VMware ESXi

Максимумы сетевого взаимодействия VMware ESXi

Мы часто пишем о встроенной утилите на хосте ESXi - esxtop, которая позволяет отслеживать все основные аспекты производительности хост-серверов и виртуальных машин (процессор, память, диски и сеть). Напомним, что наши последние посты о esxtop расположены тут, тут, тут, тут, тут и тут.

А недавно вышло весьма полезное образовательное видео "Using esxtop to Troubleshoot Performance Problems", в котором показано на практическом примере, как именно использовать esxtop для решения проблем производительности (хотя голос и весьма уныл):

Ну и напомним, что у esxtop есть графический интерфейс - это утилита VisualEsxtop.

Не так давно мы публиковали несколько интересных заметок о VMware Tools (раз, два, три, четыре), которые объясняют множество моментов, касающихся развертывания и эксплуатации данного пакета, предназначенного для улучшения работы гостевых ОС в среде виртуализации VMware vSphere.

В этой заметке мы постараемся обобщить эти вещи и добавить еще несколько фактов о VMware Tools, которые должен знать каждый администратор платформы ESXi:

• Пакет VMware Tools для основных гостевых ОС входит в состав ESXi, но остальные поставляются отдельно от дистрибутивов платформы, и их можно скачать отсюда.
• Чтобы узнать версии тулзов для ОС Windows и Linux, идущие вместе с дистрибутивом ESXi или патчем, загляните по этой ссылке https://packages.vmware.com/tools/versions (а мы писали об этом вот тут).
• Стандартные VMware Tools, которые подходят для большинства ОС Windows и Linux можно обновлять через VMware Update Manager (VUM). Они накатываются в виде VIB-пакетов под названием "tools-light".
• Традиционный подход к обновлению VMware Tools на множестве хостов VMware ESXi - это использовать общий репозиторий для VMware Update Manager, который накатывает обновления на серверы. Более современный подход - это использовать механизм Auto Deploy для развертывания stateless-хостов, которые забирают актуальные версии VMware Tools прямо из онлайн-репозитория VMware.
• Версии VMware Tools состоят из двух релизов - VMware Tools 10.1.x и VMware Tools 10.0.x (это два разных ISO-образа). Версия 10.1.x - это развивающаяся ветка для современных гостевых систем (сейчас актуальна 10.1.15), а 10.0.12 - замороженная, которая предназначена для устаревших ОС, которые уже не обновляются. То есть апгрейд с версии тулзов 10.0.9 происходит на 10.1. Подробнее об этом рассказано в KB 2015161.

• Почти все Linux-дистрибутивы идут с интегрированной версией Open VM Tools.
• ISO-файлы VMware Tools теперь идут с файлами контрольных сумм, по которым можно проверить соответствие пакетов на аутентичность их происхождения за счет сверки хэшей. Поэтому надо быть внимательным при распаковке составляющих пакета, и ничего оттуда не убирать.
• Для VMware Tools, начиная с версии 10.1, доступна подробная документация.
• Все новые версии VMware Tools обратно совместимы со всеми версиями VMware ESXi, которые моложе как минимум на одно поколение. В этом можно убедиться, посмотрев VMware Interoperability Matrix:

• Для Linux существует 3 вида VMware Tools (подробнее тут):
  • Operating System Specific Packages (OSP) - пакеты, которые размещены на сайте VMware (их можно скачать/обновить без аутентификации), содержащие в себе те же самые компоненты, которые находятся в ISO-образах, идущих с дистрибутивами VMware ESXi. Этот метод поставки VMware Tools для Linux уже несколько устарел и используется для старых гостевых ОС.
  • Open VM Tools (OVT) - это пакеты VMware Tools с открытым исходным кодом, которые встраиваются в большинство современных Linux-дистрибутивов. Соответственно, при установке такой гостевой ОС в виртуальной машине, пакет VMware Tools будет там уже установлен. Исходный код OVT доступен для всех желающих в репозитории на GitHub, но официально поддерживаются только те OVT, которые идут вместе с дистрибутивами Linux. Если вы скомпилировали их самостоятельно - учтите, поддержки от VMware не будет.
  • TAR Tools - они предоставляются VMware и устанавливаются через сценарий. Но VMware рекомендует использовать OVT.
• VMware Tools дают множество возможностей для виртуальной машины и гостевой ОС, обо всех них написано вот тут.
• Виртуальные машины с Windows используют паравиртуализованные драйвера хранилищ и сетевых адаптеров, что улучшает взаимодействие гостевой ОС и соответствующих ресурсов. Вот почему после обновления тулзов машина хочет перезагрузиться.
• Для унификации развертывания VMware Tools нужно настроить централизованный репозиторий и сконфигурировать хосты ESXi таким образом, чтобы они брали последние версии тулзов оттуда. Об этом мы подробно писали вот тут, также вкратце информация есть об этом здесь и здесь.

Если у вас есть еще интересные моменты на эту тему - пишите в каменты!

С момента выпуска прошлой версии VMware ESXi Embedded Host Client 1.23 прошло довольно много времени (аж три месяца), и вот на днях компания VMware выпустила обновление - Host Client 1.24 (спасибо Илье за новость). Напомним, что это решение позволяет управлять отдельными хостами VMware ESXi через веб-интерфейс, построенный на базе HTML5. Для управления всей инфраструктурой vSphere используется vSphere Client.

Посмотрим на новые возможности VMware ESXi Embedded Host Client 1.24:

• Пофикшена ошибка при развертывании образа OVF/OVA с дисками, привязанными к нескольким дисковым контроллерам.
• Корректная обработка адресов (проблемы race condition) при добавлении сетевого адаптера виртуальной машине.
• Возможность просматривать хранилища VVol из datastore browser.
• Решена проблема с таймаутом, когда клиент получает от хоста неизвестный тип хранилища.
• Решена проблем с автостартом ВМ.
• Теперь можно загружать VMDK-файлы типа Flat через datastore browser.
• Показ корректной строчки VMware Tools в свойствах VM summary.
• Паджинация в VM editor, когда ВМ имеет много дисков.
• Поддержка свойств OVF с предопределенными значениями и показ комбобоксов для них.
• Возможность изменения пермиссий пользователя root.
• Поддержка выбора зависимых PCI-устройств при включении режима проброса устройства (passthrough).
• Минорные исправления ошибок.

Напомним, что для установки Host Client используется команда (также его можно обновить прямо из клиента, используя пункт Update):

ssh root@<esx ip or hostname> esxcli software vib install -v <URL>

где <URL> - это локальный путь или веб-адрес VIB-пакета.

Загрузить ESXi Embedded Host Client 1.24 можно по этой ссылке (там же можно скачать и VMware Remote Console, выбрав ее из списка объектов загрузки).

Рано или поздно каждый администратор приходит к тому, что ему необходимо каким-то образом сохранить, а потом и извлечь учётные данные. Причём это должно быть быстро, эффективно, удобно и самое главное безопасно. Ни один из известных мне способов не отвечал всем этим требованиям одновременно. Я стал искать и нашел свой способ, которым и хочу поделиться с вами. Это PowerCLI! Удивлены? Порой самое простое решение лежит на поверхности.

Наш читатель Стас обратил внимание на то, что в начале ноября компания VMware выпустила значительное обновление для шестой версии платформы виртуализации VMware vSphere 6.0. Были опубликованы апдейты и патчи для ESXi 6.0 - ESXi600-201711001.

В составе гипервизора и прочих компонентов были обновлены следующие пакеты ESXi 6.0:

• VMware_bootbank_esx-base_6.0.0-3.79.6921384
• VMware_bootbank_vsan_6.0.0-3.79.6766495
• VMware_bootbank_vsanhealth_6.0.0-3000000.3.0.3.79.6769065
• VMware_bootbank_esx-dvfilter-generic-fastpath_6.0.0-3.79.6921384
• VMware_bootbank_misc-drivers_6.0.0-3.79.6921384
• VMware_bootbank_ipmi-ipmi-devintf_39.1-5vmw.600.3.79.6921384
• VMware_bootbank_ipmi-ipmi-msghandler_39.1-5vmw.600.3.79.6921384
• VMware_locker_tools-light_6.0.0-3.76.6856897

Обновления коснулись новых возможностей, подсистемы безопасности и исправлений наиболее серьезных ошибок. Чтобы скачать апдейт, нужно пойти на VMware Patch Portal, выбрать ESXi 6.0 и ввести там номер билда (6921384).

Правильно устанавливать обновление нужно следующими командами (если, конечно, на хосте есть интернет):

esxcli network firewall ruleset set -e true -r httpClient

esxcli software profile update -p ESXi-6.0.0-20171104001-standard -d https://hostupdate.vmware.com/software/VUM/PRODUCTION/main/vmw-depot-index.xml

esxcli network firewall ruleset set -e false -r httpClient

Кроме того, на днях также было выпущено обновление VMware vCenter 6.0 Update 3c. Там появилось три основных новых улучшения:

• Включенная поддержка SMB2 для виртуального модуля vCenter Server Appliance 6.0 Update 3c, чтобы избежать уязвимости протокола SMB1.
• Совместимость с решениями VMware vSphere Replication 6.1.2.1 и VMware Site Recovery Manager 6.1.2.1.
• Улучшения кластеров VMware Storage DRS.

Получить больше информации об обновлении VMware vCenter 6.0 Update 3c можно по этим ссылкам:

• VMware-VIMPatch-6.0.0-7037384-20171101.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-TP.iso
• VMware-vCenter-Server-Appliance-6.0.0.30300-7037817-patch-FP.iso

Скачать vCenter 6.0 u3c можно по этой ссылке.

Дункан написал интересный пост про работу кластера откзоустойчивых хранилищ VMware vSAN совместно с технологией отказоустойчивости хост-серверов VMware HA. Суть проблемы заключается в том, что кластер vSAN, как правило, организуется на базе обычной Ethernet-сети, которая не подразумевает наличие дополнительных хранилищ Heartbeat Datastores (на которых создаются специальные локи на файлы со стороны хостов).

А эти хранилища очень важны для кластеров VMware HA, так как по ним через сеть хранения данных (например, общие FC-хранилища) он определяет остались ли хосты работающими в случае отказа/разделения сети передачи данных, а также продолжают ли там работать виртуальные машины.

Если таких хранилищ в кластере vSAN нет (а их, скорее всего, нет), то могут возникнуть проблемы вот какого плана. В случае изоляции хоста (например, разделилась сеть или отказали порты коммутатора), сам кластер vSAN обрабатывает ситуацию корректно, но виртуальные машины продолжают быть запущены на изолированных хостах. В то же время, главная часть кластера HA (та, в которой остался Master) имеет копии этих же виртуальных машин и может запустить их, подумав, что они уже недоступны вместе с хостами, а это уже может привести к ситуации с дубликатами машин и их MAC/IP адресов, когда сеть восстановится.

Чтобы этого не происходило, на хостах ESXi нужно настроить реакцию на событие изоляции (isolation response). Хост декларирует себя изолированным при совместном наступлении двух событий:

• Он не получает коммуникации от хоста Master
• Он не может достучаться до isolation address

Если вы ничего не настраивали дополнительно в кластере HA, то ваш isolation address находится в Management network, которая и есть та сеть, в которой работает кластер vSAN (и которая, как мы помним, упала). И, на самом деле, это хорошо! Ведь если бы этот адрес продолжал быть доступен, то изолированная часть кластера не считала бы себя изолированной и случился бы split-brain с появлением возможных дубликатов машин.

Из этой всей ситуации можно сделать 3 вывода:

• Используйте отдельные от кластера vSAN хранилища Heartbeat Datastores, работающие в другой сети или по другим интерфейсам (если это возможно, конечно, в вашей инфраструктуре). Для этого нужно выбрать опцию "Use datastore from only the specified list" в настройках HA и добавить расширенную настройку "das.ignoreInsufficientHbDatastore = true" в advanced HA settings.
• Всегда ставьте действие isolation response в Power Off, чтобы машины выключились в случае изоляции хостов кластера HA, а главная часть кластера могла их перезапустить.
• Делайте isolation address в той же сети, что и основная сеть vSAN (интерфейсы VMkernel хостов), чтобы в случае изоляции хост ESXi считал себя изолированным, а не продолжающим нормально пинговать какой-то сторонний адрес. Для этого можно использовать Switch Virtual Interface (SVI) на физическом коммутаторе (если у вас немаршрутизируемая сеть vSAN).

Ну и напомним тут нашу подробную статью о совместном существовании vSAN и HA.

Автор известного технического блога о платформе VMware vSphere, Frank Denneman, совместно с одним из коллег выпустил весьма интересную книгу "vSphere 6.5 Host Resources Deep Dive".

В рамках 570-страничного талмуда авторы рассказывают все технические детали управления ресурсами на уровне хоста ESXi, такими как память, процессор, стек работы с хранилищами и сетевая архитектура. Довольно много содержимого книги посвящено архитектуре NUMA-узлов и оперативной памяти, механикам работы CPU и ядра VMkernel, а также прочим самым глубоким моментам программных и аппаратных компонентов хоста ESXi.

По уверению авторов книга покрывает, например, следующие технические вопросы:

• Оптимизация рабочих нагрузок для систем Non-Uniform Memory Access (NUMA).
• Объяснение того, как именно работает механика vSphere Balanced Power Management, чтобы получить преимущества функциональности CPU Turbo Boost.
• Как настроить компоненты VMkernel для оптимизации производительности трафика VXLAN и окружений NFV.

В общем, книга очень крутая и мудрая. Скачать ее можно по этой ссылке.

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

Правильно делать это следующим образом.

1. Проверяем, является ли хост членом кластера vSAN:

esxcli vsan cluster get

2. Выводим хост ESXi из кластера:

esxcli vsan cluster leave

3. Убедимся, что хост вышел из кластера:

esxcli vsan cluster get

мы должны получить сообщение:

Virtual SAN Clustering is not enabled on this host

4. После этого надо очистить конфигурацию vSAN для дисков на хосте.

Для начала найдем все диски командой:

esxcli vsan storage list

далее идентифицируем диски vSAN, выполнив команду:

partedUtil getptbl <путь к устройству>

Здесь мы видим, что один из разделов еще видит себя частью vSAN. Сначала надо снять лок с диска, отключив автоуправление со стороны кластера vSAN (то есть, разрешаем ручные операции с хранилищами vSAN):

esxcli vsan storage automode set --enabled false

Если этого не сделать, мы получим такую ошибку:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

5. После этого можно окончательно вывести диск из кластера vSAN следующей командой:

esxcli vsan storage remove -s naa.50026b724712194a

здесь опция -s значит SSD-диск (так отключаются устройства кэширования), а если мы хотим вывести обычный диск, то вместо -s надо использовать опцию -d.

Как часто вам приходится увеличивать логические диски внутри гостевых ОС ВМ? Довольно часто, не так ли? Вам надо сначала найти вашу ВМ в vSphere Client, потом кликнуть Edit Settings и перво-наперво увеличить виртуальный диск ВМ. После вы должны будете открыть RDP к вашей ВМ, затем открыть Disk Management, выбрать Rescan Disks из контекстного меню и только после этого ещё один правый клик на нужном вам логическом диске и вот сейчас выбрать Extend Volume...

Один из блоггеров, пишущих о платформе VMware vSphere (у него есть кстати симулятор экзамена VCDX), выложил на GitHub интересный документ, который может оказаться полезным администраторам больших виртуальных инфраструктур и сотрудникам системных интеграторов - vTestPlans.

Это документ, доступный в форматах Microsoft Word и PDF, представляет собой план тестирования виртуальной инфраструктуры VMware vSphere. Да, пока он еще весьма небольшой и очень приблизительный, но автор уверяет, что будет развивать и расширять его, в том числе за счет помощи от участников сообщества VMware.

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

Один из наших читателей обратил внимание на то, что недавно компания VMware выпустила существенное обновление VMware vSphere 5.5, в котором присутствует немало исправлений ошибок.

Первое - это патч для VMware ESXi 5.5 от 14 сентября (ESXi-5.5.0-20170904001-standard, билд 6480324). В нем пофикшены проблемы с виртуальными MAC-адресами, зависающими VMX-процессами, вылетами гипервизора в розовый экран, зависанием всего хоста ESXi, замедлением работы виртуальных машин и многое другое. В общем, патч обязательно надо накатить, если вы все еще используете версию 5.5.

Скачивается патч через Download Center:

Как накатывать патчи на ESXi 5.x мы писали вот тут.

Второе обновление - это апдейт сервисов vCenter 5.5, также от 14 сентября.

Тут были обновлены следующие компоненты:

• vCenter Single Sign-On
• vCenter Inventory Service
• vCenter Server
• vSphere Web Client
• vRealize Orchestrator (бывший vCenter Orchestrator)
• vSphere Update Manager

Некоторые из вас знают, что, начиная с версии vSAN 6.2, стало возможно создание "тонких" (thin) файлов подкачки. В более ранних версиях vSAN было возможно создавать только reserved своп-файлы, что требовало довольно больших объемов дисковой памяти. То есть, если у машины 16 ГБ оперативной памяти, то в два раза больше будет занято и на диске под своп (32 ГБ), так как при FTT=1 (failures to tolerate) дисковые объекты дублируются в рамках кластера.

Поэтому для сред, в которых достаточно памяти у хостов, и отсутствует Memory Overcommitment, сделали параметр в настройках кластера SwapThickProvisionDisabled, позволяющий виртуальным машинам создавать тонкие файлы подкачки.

Чтобы выставить эту настройку, есть специальный скрипт PowerCLI, который применяет ее ко всем хостам ESXi кластера vSAN.

Однако выставить настройку недостаточно - ведь, чтобы файлы подкачки стали тонкими, то есть пересоздались, надо перезагрузить (выключить и включить) виртуальные машины с толстыми swap-файлами. Найти такие машины позволит вот этот Python-сценарий. Ну а дальше уже перезагрузите машины по списку - это позволит вам сэкономить значительный объем дискового пространства кластера.

На прошедшей недавно конференции VMworld 2017 компания VMware представила несколько интересных продуктов и технологий. Наиболее полезные сессии мероприятия доступны здесь.

Одна из таких сессий посвящена углубленному решению проблем инфраструктуры серверов ESXi - "Advanced Troubleshooting of ESXi Server 6.x for vSphere Gurus":

В рамках сессии рассказали о трех ключевых категориях для траблшутинга хостов ESXi - 7 лог-файлов, 7 команд консоли и 7 конфигурационных файлов.

Среди этих 7 лог-файлов:

• Если хост вдруг перезагрузился, смотрите в vmksummary.log.
• Если у вас ESXi грузится медленно, то проверьте /var/log/boot.gz (также можно включить логгирование через последовательный порт с помощью нажатия Shift + o при загрузке, см. KB 1033888).
• Если ESXi не отвечает, то нужен анализ логов hostd.log и hostd-probe.log.
• Если проблемы в виртуальной машиной, надо идти в vmware.log.
• Если проблемы с хранилищем, смотрим в vmkernel.log.
• Если проблемы с сетью и сетевым хранилищем, проверяем vobd.log.
• Ну а для диагностики HA смотрим в fdm.log, а также выполняем команду /opt/vmware/fdm/prettyprint.sh hostlist | less.

7 основных команд:

• Для мониторинга и настройки используем – esxcli.
• Для получения системной информации VMkernel – vsish get /bios; /hardwareinfo;

• Для управления серверами ESXi и конфигурациями ВМ - vim-cmd:

• Для управления томами VMFS и виртуальными дисками машин – vmkfstools.
• Просмотр детальных статистик по памяти – memstats.
• Захват сетевых пакетов – pktcap-uw.
• Мониторинг производительности хоста – esxtop.

7 основных конфигурационных файлов:

• /etc/vmware/esx.conf – хранилище, сети и информация об оборудовании.
• /etc/vmware/hostd/vminventory.xml – окружение виртуальных машин на хосте.
• /etc/vmware/hostd/authorization.xml – соединение vCenter к хосту ESXi.
• /etc/vmware/vpxa/vpxa/cfg – параметры взаимодействия vCenter и ESXi.
• /etc/vmware/vmkiscsid/iscsi.conf – конфигурация iSCSI.
• /etc/vmware/fdm – конфигурация VMware HA.
• /etc/vmware/license.cfg – настройка лицензии.

Остальные детали смотрите в записи сессии.

На днях компания VMware выпустила утилиту DRS Dump Insight, описание которой доступно на сайте VMware Labs. Это портал самообслуживания, куда пользователи могут загружать файлы дампов DRS. После этого будет выведена информация об операциях по перемещению виртуальных машин, которые рекомендует выполнить механизм балансировки нагрузки DRS :

Утилита DRS Dump Insight позволит ответить на следующие вопросы:

• Почему DRS выдал конкретную рекомендацию (улучшить баланс по CPU, по памяти и т.п.)?
• Почему DRS не вырабатывает рекомендации по балансировке кластера?
• Какие рекомендации DRS выработал для анализа cost/benefit (затраты/выгоды)?
• Можно ли получить список вообще всех рекомендаций, выданных DRS?

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

Вот так выглядит этот отчет (его можно экспортировать в PDF):

Нажав "Show" можно увидеть исходный и целевой хосты ESXi, для которых сформирована рекомендация по перемещению ВМ в данной категории.

Также в утилите доступна аналитика вида "что если?" (what-if analysis), которая позволяет смоделировать следующие ситуации:

• Изменение пороговых значений миграции (DRS Migration Threshold).
• Удаление правил affinity/anti-affinity rules в кластере.
• Изменение расширенных настроек DRS.

Средство DRS Dump Insight будет очень полезно Enterprise-администраторам, ищущим средство для аналитики, тонкого тюнинга DRS и оптимизации миграций vMotion в рамках больших кластеров. Утилита доступна по адресу https://www.drsdumpinsight.vmware.com/.

Недавно мы писали о новых возможностях обновленной версии веб-клиента для управления отдельными хост-серверами VMware ESXi Embedded Host Client 1.23, и нам задали вопрос - а как его правильно обновлять?

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

1. Скачать VIB-пакет VMware ESXi Embedded Host Client или любой другой VIB-пакет, который вы хотите обновить. Далее нужно положить его на любой доступный Datastore:

2. Далее в меню Help в правом верхнем углу клиента нужно выбрать пункт Update:

3. После этого вас попросят ввести путь к VIB-пакету на датасторе, на который вы только что его положили (этот путь можно скопировать из Putty):

Напомним, что так можно обновлять любой VIB-пакет, а не только сам ESXi Embedded Host Client.

4. Если что-то пойдет не так, ошибки будут записаны в /var/log/esxupdate.log - его можно будет использовать для траблшутинга:

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

Одновременно с релизом тонкого клиента для управления виртуальной инфраструктурой VMware vSphere Client 3.19 компания VMware выпустила и обновление веб-клиента для управления отдельными хост-серверами ESXi Embedded Host Client 1.23. Напомним, что прошлая его версия 1.21 вышла 2 месяца назад - в середине июня.

Клиент для ESXi получил следующие новые возможности (в основном, это исправления ошибок):

• Отображение списка виртуальных машин в настройках автостарта для хост-сервера.
• Пофикшен баг с выбором роли в Internet Explorer 11.
• Портлет с информацией о разделах теперь работает корректно.
• Улучшенная обработка разделов неизвестных типов.
• Исправлена проблема с дробным числом ядер на процессор в настройках ВМ (ха-ха-ха, ну и баг!).
• Несколько исправлений различных мастеров.
• Убрано неубираемое ранее оповещение при импорте ВМ о том, что она содержит floppy drive.
• Поправлено скрытое выделение непоказываемых объектов, когда пользователь нажимает Select All в отфильтрованном списке ВМ (тоже детский баг!).
• Обработка виртуальных модулей OVA при отсутствующем поле Description (и этот!).
• Теперь доступные сетевые физические интерфейсы NIC отображаются корректно.
• При форматировании тома VMFS дефолтно выбирается последняя версия файловой системы.
• Добавлено несколько обновлений безопасности.

Скачать новую версию VMware ESXi Embedded Host Client 1.23 можно по этой ссылке (надо отметить, что через функцию Update в клиенте из состава vSphere 6.5 обновления видно не будет).

На днях вышел интересный отчет компании Principled Technologies, специализирующейся, в том числе, на всякого рода тестировании аппаратно-программных сред. В документе "VMware vSphere memory overcommitment delivered greater VM density than Red Hat Virtualization" рассказывается о том, что на одном и том же оборудовании с помощью гипервизора ESXi можно запустить больше виртуальных машин, чем на гипервизоре KVM платформы RHEV.

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

Для тестирования использовался стоечный сервер Lenovo x3650 M5, на котором в виртуальных машинах работала СУБД Microsoft SQL Server 2016 с нагрузкой типа OLTP. В качестве основного показателя производительности использовался OPM (orders per minute), отображающий количественную оценку исполненных транзакций.

Если не использовать техники Memory Overcommit, то результат выполнения на 15 виртуальных машинах одного хоста в числе OPM примерно одинаковый на обоих гипервизорах:

А вот когда происходит увеличение числа виртуальных машин, то vSphere показывает себя значительно лучше:

Крестиками отмечены машины, которые на RHV просто не запустились, консоль продукта выдала вот такую ошибку:

Несмотря на включение техник оптимизации памяти в Red Hat Virtualization Manager (RHV-M), таких как memory ballooning и kernel shared memory, шестнадцатая виртуальная машина все равно отказывалась запускаться на KVM:

Ну а на vSphere продолжали наращивать число ВМ, пока не уперлись в недостаток ресурсов:

Получилось, что с техниками overcommit на vSphere получилось запустить 24 виртуальных машины, а на RHV - всего 15 штук. По итогу сделали вывод, что на VMware vSphere в 1,6 раза можно запустить больше виртуальных машин:

Не сказать, что это объективное тестирование, но очевидно, что ESXi в данном случае работает лучше KVM с точки зрения всяких оптимизаций памяти и прочих ресурсов ВМ.

Спустя почти 9 месяцев с момента выпуска платформы VMware vSphere 6.5, компания VMware анонсировала первый пакет ее обновления - VMware vSphere 6.5 Update 1. Но в таком долгом сроке обновления есть и большой плюс - ведь наверняка на этот раз QA-отдел VMware успел хорошо проверить новый релиз, поэтому критических багов после обновления вылезти не должно (их, кстати, согласно списку Release Notes было немало исправлено). Тем не менее, как обычно мы советуем вам подождать недельку другую перед обновлением на новую версию:)

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

1. vSphere Client теперь поддерживает 90% рабочих процессов.

Последний релиз vSphere Client на базе технологии HTML5 поддерживает практически все рабочие процессы, за исключением некоторых нечасто используемых операций. Совсем немного осталось до стопроцентного покрытия (хотя нам это говорили уже несколько месяцев назад). Надо отметить, что теперь полностью поддерживаются операции с Virtual Distributed Switch (VDS).

2. vCenter Server Foundation теперь поддерживает 4 хоста ESXi вместо трех.

Это сделано по просьбам клиентов, имеющих небольшую инфраструктуру и требующих одну лицензию на vCenter на четное число хостов.

3. Расширенная поддержка сторонних компонентов.

VMware поработала с основными партнерами, решения которых дополняют инфраструктуру vSphere, и выработала подход, который позволит избежать проблем совместимости различных версий платформы в будущем с такими компонентами, как Security Key Management, Proactive HA и т.п.

4. Расширенная поддержка vSphere 6.5 General Support.

VMware решила расширить поддержку платформы vSphere 6.5 до 5 лет, что означает, что она закончится 15 ноября 2021 года.

5. Апгрейд на vSphere 6.5 U1 c vSphere 6.0 U3.

VMware полностью поддерживает рабочий процесс обновления последней версии vSphere 6.0 U3 предыдущего поколения на актуальную версию vSphere 6.5 Update 1. То есть, теперь нет необходимости промежуточного обновления на vSphere 6.5.

6. Обновления драйверов.

Следующие драйвера устройств были обновлены в составе гипервизора ESXi 6.5 Update 1:

• Cavium qlnativefc driver
• VMware nvme driver
• Intel i40en driver with Lewisburg 10G NIC Support
• Intel ne1000 driver with Lewisburg 1G NIC Support
• Intel igbn driver
• Intel ixgben driver
• Broadcom ntg3 driver

7. Улучшения максимумов vCenter.

Теперь у vCenter следующие максимально поддерживаемые параметры (vSphere Domains - это SSO-домены):

• Maximum vCenter Servers per vSphere Domain: 15 (было 10)
• Maximum ESXi Hosts per vSphere Domain: 5000 (было 4000)
• Maximum Powered On VMs per vSphere Domain: 50,000 (было 30,000)
• Maximum Registered VMs per vSphere Domain: 70,000 (было 50,000)

8. Другие улучшения vCenter.

• Интерфейс установщика vCenter Server Appliance (vCSA) доступен для Microsoft Windows 2012 x64, Microsoft Windows 2012 R2 x64, Microsoft Windows 2016 x64 и macOS Sierra.
• TcServer заменен на Tomcat 8.5.8.
• Поддержка кастомизации гостевой ОС Ubuntu 17.04.
• Возможность использования vSphere Update Manager для обновления кластеров vSAN 6.6.1.

• Поддержка внешних СУБД Microsoft SQL Server 2016, Microsoft SQL Server 2016 SP1 и Microsoft SQL Server 2014 SP2.

Кстати, это последний релиз который поддерживает сторонние виртуальные распределенные коммутаторы, такие как IBM DVS 5000v, HPE 5900v или Cisco Nexus 1000v. В следующем релизе их больше нельзя будет использовать, поэтому осваивайте vDS от VMware. Более подробная информация об этом приведена в KB 2149722.

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

• VMware vCenter Server 6.5 U1 [Release Notes] [скачать]
• VMware vSphere Hypervisor (ESXi) 6.5 U1 [Release Notes] [скачать]
• VMware vSphere Replication 6.5.1 [Release Notes] [скачать]
• VMware Tools 10.1.10 [Release Notes] [скачать]
• VMware vRealize Orchestrator Plug-In for vSphere Replication 6.5.1 [Release Notes] [скачать]
• VMware vSAN Management SDK 6.6.1 [скачать]
• VMware vSAN Witness Appliance 6.5 U1 [скачать]
• VMware vSphere Virtual Disk Development Kit 6.5 U1 [скачать]
• VMware vSphere Web Client SDK 6.5 U1 [скачать]
• VMware Identity Manager 2.9.2 [Release Notes] [скачать]
• VMware Site Recovery Manager 6.5.1 [Release Notes] [скачать]

В VMware vSphere есть механизм для создания и анализа кастомных алармов - VMkernel Observations (VOBs). VOB'ы - это системные события, которые можно использовать для пользовательских алармов в целях отладки различных аспектов виртуальной инфраструктуры (сетевого взаимодействия, кластеров vSAN, производительности и т.п.).

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

/usr/lib/vmware/hostd/extensions/hostdiag/locale/en/event.vmsg

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

/var/log/vobd.log

Для того, чтобы создать кастомный аларм на основе VOB, нужно при создании нового аларма выбрать пункт "specific event occuring on this object":

И далее добавить соответствующий идентификатор, например, такой:

esx.problem.vob.vsan.pdl.offline

Событий, для которых можно создать кастомные алармы, очень много. Вот некоторые из них:

Ну а вот так вот будет выглядеть сработавший кастомный аларм в интерфейсе VMware vSphere Web Client:

Спустя 8 лет, опять поднимем тему использования кластеров VMware HA/DRS, в которых, по каким-либо причинам, оказались разные версии хост-серверов VMware ESXi. Такой режим работы кластеров допускается со стороны VMware, но при определенных условиях.

Первая и самая важная вещь - совместимость виртуального аппаратного обеспечения виртуальных машин (Virtual Hardware Version), которое увеличивает свою версию с каждым мажорным релизом ESXi. Правило тут простое - более новые версии ESXi могут запускать и исполнять виртуальные машины более старых версий, а вот старые хосты ESXi более новое для себя "виртуальное железо" не запустят.

Данный момент проясняет табличка из KB 2007240:

Обратите внимание, что, например, ВМ с версией HW 11 вы не запустите на ESXi 5.5. Поэтому выход такой - не обновлять старое виртуальное аппаратное обеспечение виртуальных машин, даже если они переехали за счет vMotion на хосты с более новой версией HW.

Второй момент - VMware Tools. Тут уже проще - старую версию тулзов можно эксплуатировать на новых хостах, как и новую на старых - обратная совместимость тоже есть. Убедиться в этом можно с помощью онлайн-утилиты VMware Product Interoperability Matrices, где в поле "Select a Solution" надо выбрать VMware Tools, а в поле "Add Platform/Solution" - платформу VMware vSphere Hypervisor (ESXi):

Но обратная совместимость тоже не бесконечная - VMware Tools версии 10.1.5, как мы видим, не получится использовать на VMware vSphere 5.1 Update 3.

Кстати, чтобы обновить VMware Tools, можно переместить ВМ с помощью vMotion на хост ESXi с более высокой версией и выбрать пункт "Install/Upgrade VMware Tools" в vSphere Web Client.

Второй способ обновления VMware Tools - это просто скачать их по ссылке с официального репозитория для вашей гостевой ОС:

https://packages.vmware.com/tools/esx/index.html

Ну и третий, заключительный, но самый важный момент при использовании смешанных кластеров (VMware их называет mixed clusters) - это возможности VMware HA, DRS, FT и прочих функций, которые предоставляет соответствующая версия ПО от VMware.

Например, в версии vSphere 6.5 появилось много нового с точки зрения технологии HA (к примеру, механизм Admission Control стал рассчитывать параметры для несбалансированных кластеров автоматически).

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