Недавно мы писали об обновлении на сайте проекта VMware Labs пакета Community Networking Driver for ESXi до версии 1.2.2, который представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. На днях на сайте Labs вышли обновления еще двух пакетов драйверов.
1. NVMe Driver for ESXi версии 1.2
Это набор драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах. О прошлой версии мы писали вот тут, а в новой версии нововведение только одно - поддержка ESXi 7.0 и более новых версий гипервизора для устройств Apple NVMe (это Apple 2018 Intel Mac Mini 8.1 или Apple 2019 Intel Mac Pro 7.1).
Скачать пакет драйверов Community NVMe Driver for ESXi 1.2 можно по этой ссылке.
2. USB Network Native Driver for ESXi версии 1.9
Это нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов. О прошлой версии этих драйверов мы писали вот тут.
В версии пакета драйверов 1.9 появились следующие нововведения:
Добавлена поддержка ESXi 7.0 Update 3
Добавлена поддержка VID: 0x0b05/PID: 0x1976 и VID: 0x1A56/PID: 0x3100 (VID=VendorID, PID = ProductID)
Исправлена проблема с функциями управления питанием для xHCI
По умолчанию функция USB bus scanning отключается (настройка usbBusFullScanOnBootEnabled=0), чтобы не вызывать розовый экран смерти (PSOD) для пользователей, которые используют несколько карточек USB NIC.
Таблица поддерживаемых устройств теперь выглядит так:
Скачать USB Network Native Driver for ESXi версии 1.9 можно по этой ссылке (не забудьте корректно указать вашу версию ESXi при загрузке).
На сайте проекта VMware Labs появилось еще одно полезное средство для администраторов виртуальной инфраструктуры - vSphere Diagnostic Tool. Оно представляет собой python-скрипт, который запускает диагностические команды на виртуальном модуле Photon OS (на его базе построен, например, vCenter Server Appliance), а также в перспективе это будет работать и в среде VMware ESXi.
Основное назначение данной утилиты - дать администраторам быстрое средство траблшутинга, которое они могут использовать для первичной идентификации наиболее распространенных проблем. Если все проверки пройдут успешно, то дальше уже можно более глубоко изучать логи и проводить дополнительные тесты.
Интересно, что данный продукт уже был протестирован во внутренней команде поддержки VMware, которая опробовала его на реальных пользователях.
Для vCenter Server Appliance 6.5 или более поздней версии можно выполнить следующие тесты:
Базовая информация о vCenter
Проверка Lookup Service
Проверка AD
Проверка сертификатов vCenter
Проверка основных файлов (Core File)
Проверка диска
Проверка vCenter DNS
Проверка vCenter NTP
Проверка портов vCenter
Проверка аккаунта Root
Проверка служб vCenter
Проверка механизма VCHA
В качестве результатов будет выдан один из статусов Pass/Warning/Fail, а также для статусов Warning и Fail выводятся ссылки на статьи KB, которые могут пригодиться для решения проблем в данной категории.
Команда заявляет, что в бэклоге проекта еще более 100 планируемых фич, поэтому следите за обновлениями скриптов. Скорее всего, данное средство включат в будущем в состав инфраструктурных продуктов линейки VMware vSphere для проверки виртуальных модулей на базе Photon OS (а это уже почти все продукты, построенные на базе хостовой ОС Linux, вроде vCSA).
Скачать vSphere Diagnostic Tool можно по этой ссылке.
Таги: VMware, vSphere, vCSA, Labs, Troubleshooting, ESXi, Support
Многим из вас знакомы продукты компании StarWind, предназначенные для создания отказоустойчивых хранилищ под различные платформы виртуализации. Сегодня мы поговорим о том, как настраивать аутентификацию доступа к хранилищам через протокол CHAP в решении StarWind Virtual SAN...
Таги: StarWind, iSCSI, Storage, Security, ESXi, VMware, Microsoft, Hyper-V, HA
Этот пакет представляет собой комплект нативных драйверов под ESXi для сетевых адаптеров, подключаемых в разъем PCIe. О прошлой версии этих драйверов мы писали весной этого года вот тут. В данном обновлении были добавлены драйверы для устройств Intel I225/I226/I220/I221.
Драйверы работают для VMware ESXi 7.0 или более поздних версий, а список поддерживаемых устройств сейчас выглядит так:
Скачать Community Networking Driver for ESXi можно по этой ссылке.
Компания VMware, вскоре после большого обновления vSphere 7 Update 3, выпустила небольшой апдейт vSphere 7 U3a. С момента прошлого релиза прошло около месяца, поэтому нововведений не так много. Напомним, что в Update 3 для администраторов и DevOps появилась возможность использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.
Теперь в Update 3a эта возможность позволяет вновь созданным виртуальным машинам стать частью кластера TKG (Tanzu Kubernetes Grid) с нативным исполнением команд. Это позволит:
Компаниям использовать кластеры TKG как платформу Kubernetes с GPU-ускорением для нагрузок AI/ML.
Администраторам получить инструмент быстрой и эффективной совместной работы над развертыванием и обслуживанием инфраструктуры контейнеров и уйти от рабочего процесса коммуникации на базе тикетов.
Инфраструктура Tanzu Kubernetes (TKr) теперь построена на Ubuntu 20.04 - сам образ был оптимизирован для использования с нагрузками AI/ML и тщательно оттестирован. Детальное руководство об использовании сервисов Tanzu для AI/ML находится в этой статье.
Компания VMware обновила свою версию гипервизора для архитектуры ARM - версия ESXi Arm Edition
1.6 стала доступна на сайте проекта VMware Labs. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлой версии этой платформы мы писали вот тут.
Новые возможности ESXi Arm Edition
1.6:
Экспериментальная поддержка инстансов BM.Standard.A1.160 на базе Ampere Altra в инфраструктуре Oracle Cloud
Напомним, что разработка версии ESXi для архитектуры ARM очень важна в рамках программно-аппаратного подхода Project Monterey, почитать об этом можно вот тут. Скачать новую версию ESXi Arm Edition
1.6 можно по этой ссылке.
Кстати, у VMware есть отдельный блог, посвященный работе ESXi на архитектуре ARM: blogs.vmware.com/arm.
Недавно компания VMware выпустила обновление VMware vSphere 7 Update 3, которое стало доступным для загрузки накануне уже прошедшей конференции VMworld Online 2021. В рамках конференции VMware рассказала о перспективах развития технологий своих серверных и десктопных продуктовых линеек, в которых ожидается много интересных нововведений в самом ближайшем будущем. Сегодня мы поговорим о трех основных анонсах...
Вчера мы писали о новых возможностях анонсированного недавно обновления платформы виртуализации VMware vSphere 7 Update 3. Сегодня мы чуть детальнее разберем возможности обновленного продукта, касающиеся хранилищ виртуальных машин. Нововведения были сделаны в следующих областях:
1.Поддержка NVMe over TCP
В релизе vSphere 7.0 была анонсирована поддержка технология NVMe over Fabrics, где первоначально поддерживались только протоколы FC и RDMA. Теперь же поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка и NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Это поможет в некоторых случаях существенно сэкономить на оборудовании.
2. Увеличение числа хостов на один датастор
У VMware есть какое-то количество клиентов, которые достигли предыдущего лимита в 64 хоста ESXi на одно виртуальное хранилище VMFS или NFS. В Update 3 этот лимит был расширен до 128 хостов. Надо понимать, что к лимитам кластера это число не имеет отношения - это только число хостов, которые могут одновременно использовать датастор.
3. Affinity 3.0 и поддержка CNS
В vSphere 7 компания VMware обновила Affinity Manager до версии 2.0, который уменьшает затраты на первые операции записи для thin и lazy thick дисков. В Affinity 3.0, который вошел в этот релиз, появилась поддержка персистентных томов Cloud Native Storage (CNS), которые также называются FCD (First Class Disks). Также добавлена поддержка большего числа хостов ESXi на один кластер.
4. Пакетные снапшоты томов vVols
В этом обновлении vSphere была существенно улучшена процедура обработки большого одновременного количества снапшотов томов vVol, которая может происходит в рамках процессов обслуживания хранилищ и резервного копирования. Операции снапшотов группируются и обрабатываются в рамках пакетного процесса, уменьшается общее число операций, поэтому в итоге нагрузка на хранилища уменьшается.
Более подробно обо всех новых возможностях VMware vSphere 7 Update 3 в отношении хранилищ рассказано в этой статье.
Компания VMware перед предстоящей конференцией VMworld 2021 анонсировала скорую доступность для загрузки обновления своей главной серверной платформы виртуализации VMware vSphere 7 Update 3.
Нововведения будут сосредоточены в 3 основных областях:
Deliver AI and Developer-Ready Infrastructure
В новой версии vSphere была улучшена служба для развертывания виртуальных машин через стандартные Kubernetes API Virtual Machine (VM) Service, которая появилась в vSphere 7 Update 2a. Теперь администраторы и DevOps смогут использовать команды Kubernetes для развертывания ВМ на хостах, где включена поддержка vGPU.
Это позволит клиентам самостоятельно запускать AI-нагрузки в виртуальных машинах и просто работать с ними всем участникам процесса обслуживания виртуальной инфраструктуры.
Также было улучшено решение VMware vSphere with VMware Tanzu, которое теперь проще настраивать, особенно в части сетевого взаимодействия, на что ранее жаловались пользователи.
Создать тестовую лабораторию Kubernetes администраторам vSphere теперь стало гораздо легче.
Scale without Compromise
В этой категории улучшений больше всего изменилось в плане поддержки высокопроизводительной памяти Persistent Memory. Например, ее часто используют для таких нагрузок, как SAP HANA. Теперь в vSphere 7 Update 3 есть множество новых инструментов для анализа и настройки производительности памяти с точки зрения пропускной способности (bandwidth) и нагрузки. В дополнение к этому, теперь можно настраивать алармы на базе SLA и изменять конфигурацию машин и платформы на базе рекомендаций от механизма аналитики.
Также, поскольку SSD-хранилища продолжают набирать популярность, а транспорт Non-Volatile Memory Express (NVMe) стал стандартом для многих типов систем, в vSphere 7 Update 3 появилась поддержка NVMe over TCP, которая позволяет использовать стандартную инфраструктуру TCP/IP, оптимизированную под Flash и SSD, для трафика хранилищ. Подробнее об этом рассказано здесь.
Simplify Operations
В новой версии vSphere 7 Update 3 появился специальный vCenter Server plug-in for NSX, который позволяет администраторам гораздо быстрее и удобнее настраивать сетевое взаимодействие и безопасность для NSX прямо из vSphere Client, без необходимости использования NSX Manager. В этой категории также появился простой процесс развертывания и настройки NSX-T, а также бесшовная аутентификация пользователей между vSphere и NSX-T.
Также механизм vSphere Distributed Resource Scheduler (DRS) теперь работает умнее в плане обработки операций обслуживания. Большие и более критичные нагрузки теперь перемещаются первыми и как можно скорее, чтобы пользователи не почувствовали никакого влияния процесса миграции во время обслуживания и апгрейда серверов.
Скачать апдейт VMware vSphere 7 Update 3, который выйдет на днях, можно будет по этой ссылке. Более подробно о новых возможностях обновления также рассказано вот в этой статье.
В начале сентября компания VMware объявила о том, что ее флагманская платформа виртуализации VMware ESXi больше не будет поддерживаться для Apple 2019 Mac Pro 7,1 в целях виртуализации Mac OS систем. Причина проста - Apple осуществляет переход на архитектуру Apple Silicon, а во времена Covid затруднено технологическое партнерство между большими компаниями в этой сфере.
В последнее время в продуктах VMware часто находят различные уязвимости, а хакеры по всему миру разрабатывают различные руткиты и утилиты для взлома инфраструктуры VMware vSphere и серверов ESXi. В связи с этим многие администраторы хотели бы отключить неиспользуемые плагины, которые есть в VMware vCenter. Совсем недавно появились следующие оповещения о проблемах с безопасностью (VMware Security Advisories, VMSA), которые касаются плагинов:
CVE-2021-21985 - VMSA-2021-0010 (плагин Virtual SAN Health Check)
CVE-2021-21986 - VMSA-2021-0010 (плагины Virtual SAN Health Check, Site Recovery, vSphere Lifecycle Manager и VMware Cloud Director Availability)
Подробно об отключении плагинов у VMware написано в KB 83829. Приведем здесь данную процедуру вкратце.
В конфигурационный файл на сервере vCenter вам нужно будет добавить одну или несколько следующих строчек, в зависимости от плагина, который вы хотите отключить:
Давайте теперь посмотрим, какие плагины включены по умолчанию на всех серверах vCenter после установки (Default), а какие устанавливаются и включаются только после установки соответствующего продукта (Product):
vCenter Version
vRealize Operations
vSAN
VMware vSphere Lifecycle Manager
Site Recovery
VMware Cloud Director Availability
6.5
Default
Default
N/A
Product
Product
6.7
Default
Default
N/A
Product
Product
7.0
Default
Default
Default
Product
Default
Итак, чтобы отключить плагины, вам нужно:
Подключиться к серверу vCenter Server Appliance (vCSA) по SSH как root
Сделать резервную копию файла, например, командой: cp -v /etc/vmware/vsphere-ui/compatibility-matrix.xml /etc/vmware/vsphere-ui/compatibility-matrix.xml.backup
Открыть этот файл в текстовом редакторе командой: vi /etc/vmware/vsphere-ui/compatibility-matrix.xml
Добавить туда соответствующую строчку конфигурации из таблицы выше вот в этом месте (раздел pluginsCompatibility):
Многим Enterprise-администраторам VMware vSphere знаком сервис VMware Skyline, который позволяет проактивно получать рекомендации по технической поддержке продуктов линейки VMware vSphere, включая vSAN.
С помощью технологии VMware Skyline пользователи и инженеры технической поддержки VMware (Technical Support Engineers, TSEs) могут просматривать некоторые заключения о работе виртуальной инфраструктуры и основные рекомендации по ее улучшению, которые содержатся в специальном отчете Skyline Operational Summary Report (OSR).
Если вы хотите спрятать некоторые советы и рекомендации, которые не требуют применения в вашей инфраструктуре, вы можете использовать специальные фильтры для вывода ненужных объектов. Например, можно спрятать Trivial Findings, которые не очень важны и только мешают увидеть серьезные проблемы.
Просто в левой панели выбираете нужный фильтр и нажимаете Hide Findings в разделе Active Findings:
Эти рекомендации не удаляются - их всегда можно увидеть на вкладке Hidden Findings (см. скриншот выше).
Далее спрятанные рекомендации можно экспортировать в CSV-файл, чтобы, например, обсудить их с командой техподдержки VMware или собственной командой:
Вторая полезная функция по сокрытию рекомендаций - это возможность исключить выбранные объекты из Inventory. Для этого в левой панели нужно раскрыть дерево объектов и снять галки с ненужных. Например, это могут быть давно списанные хосты ESXi или компоненты окружения разработки и тестирования:
Ну и чтобы посмотреть описанное в действии, можете взглянуть на это видео:
На сайте проекта VMware Labs обновилась очередная интересная утилита Storage Performance Tester, которая позволяет провести тестирование хранилищ в один клик на сервере VMware ESXi, получив метрики IOPS, latency и CPU cycles per I/O. В новой версии появилась поддержка адаптеров vnvme, а также исправления ошибок для ESXi 6.7.
С помощью данного средства можно автоматизировать шаги проведения тестирования, которые включают в себя развертывание кастомизированной ВМ, запуск нагрузки по вводу-выводу внутри нее и, собственно, функции по анализу результата тестирования производительности.
Результаты для полученных метрик выводятся в графическом интерфейсе в виде диаграмм и комментариев к ним:
Самое приятное - это то, что утилита запускается одной командой, после чего пользователь получает итоговый результат. Выглядит это так:
#./sperf.py HOSTNAME -d DatastoreName
Данное средство можно использовать как для решения проблем с действующей инфраструктурой хранилищ, так и для выяснения максимальных параметров производительности только что купленного железа (диски, контроллеры, компоненты сети хранения данных).
Ну и видео о том, как это все работает:
Для запуска Storage Performance Tester вам потребуется:
Python 3
sshpass
2 ГБ свободного пространства на диске
Linux-окружение (ядро не старше 2.6.31)
Скачать Storage Performance Tester можно по этой ссылке.
Несколько дней назад на различных новостных ресурсах появилась новость о том, что хакерская группа BlackMatter (которая появилась из групп Darkside и REvil) разработала библиотеку esxi_utils, предназначенную для выполнения вредоносных операций с хост-серверами виртуализации VMware ESXi. По-сути, это Linux-шифровальщик, на базе которого строятся программы-вымогатели (Ransomware), наносящие довольно серьезный урон крупным корпорациям.
Злодеи из BlackMatter заявляют своей целью крупные компании (от $100 миллионов годовой выручки), извлеченные данные которых они планируют публиковать в открытом доступе (очевидно, только их часть), а сами данные будут зашифровывать и вымогать деньги. С точки зрения географий - это US, UK, Канада и Австралия.
В сам вредоносный пакет включены компоненты, реализующие следующие методы на C:
esxi_utils
files_proc
file_encrypter
setup_impl
web_reporter
Будучи внедренными на сервере ESXi, они позволяют выполнять там различные операции, такие как вывод списка виртуальных машин, операции по их выключению, отключение сетевого экрана и многое другое. Это нужно для того, чтобы, например, выключить виртуальные машины перед зашифровкой их дисков.
Также интерфейсы данного средства предусматривают выполнение подобных команд сразу для всей инфраструктуры в один момент времени - то есть на всех серверах все ВМ останавливаются и их диски сразу же шифруются.
Различные источники также пишут, что подобные шифровальщики существуют уже давно и доступны от многих хакерских группировок. Сигнатуры большинства подобных средств уже внесены в базы данных продуктов для защиты корпоративной инфраструктуры.
Возможно, от распространения подобного рода ПО в вашей инфраструктуре вам помогут продукты VMware Carbon Black и VMware AppDefense, а возможно и нет:)
На сайте проекта VMware Labs вышло обновление ESXi Arm Edition 1.5. Напомним, что это специальная версия гипервизора VMware, предназначенная для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлой версии этой платформы мы писали вот тут.
Кстати, есть интересное видео о продукте:
Нововведений в обновленной версии не так много:
Небольшие улучшения производительности работы виртуальных машин
Поддержка BCM2848 ACPI ID для порта USB OTG (затрагивает новые версии микрокода UEFI)
Исправления небольших ошибок
Скачать новую версию VMware ESXi Arm Edition 1.5 можно по этой ссылке. Кстати, о багах и новых обсуждениях работы этой версии гипервизора можно узнавать вот тут, а здесь находится комьюнити в Slack.
Компания StarWind Software, известная многим из вас как ведущий производитель программно-аппаратных хранилищ под виртуализацию VMware vSphere и Microsoft Hyper-V, запустила новый продукт StarWind SAN & NAS, который предназначен для создания хранилищ на основе севреров с установленным там гипервизором. В качестве платформы StarWind SAN & NAS использует Linux...
Данный Fling представляет собой пакет нативных драйверов для ESXi, которые позволяют поддерживать различные хранилища на базе технологии NVMe. Надо понимать, что community-драйверы не входят в официальный список поддержки VMware HCL, поэтому использовать их можно только в тестовых средах.
Драйверы теперь поддерживают VMware ESXi 7.0 или более поздние версии гипервизора для NVMe-хранилищ не от Apple. Пока список поддерживаемых устройств такой:
Для хранилищ Apple SSD пока поддерживается только ESXi 6.7 до версии Patch 03 (Build 16713306). Более новые версии гипервизора с NVMe-устройствами Apple, к сожалению, не работают. Пока драйверы поддерживают Apple 2018 Intel Mac Mini 8.1 и Apple 2019 Intel Mac Pro 7.1, причем подключение портов Thunderbolt 3 не поддерживется (ESXi может выпасть в PSOD).
Драйверы поставляются в виде VIB-пакета, установить который можно командой:
esxcli software vib install -d /path/to/the offline bundle zip
Скачать Community NVMe Driver for ESXi 1.1 можно по этой ссылке.
Среди открытых документов VMware появился очень интересный док - "vSphere Snapshots: Performance and Best Practices", в котором рассматривается весьма полезные многим администраторам аспекты - производительность снапшотов, а также, как правильно с ними обращаться. Мы часто пишем про это (1, 2, 3), а вот теперь есть и хороший документ с картинками.
Основные темы документа:
Что такое снапшоты
Какие есть форматы снапшотов
Описание тестового окружения и рабочих нагрузок
Результаты тестирования производительности
Выводы по этим результатам
Итак, для тестирования использовались следующие рабочие нагрузки:
FIO (стандартный тест производительности ввода-вывода)
JVM (бенчмарк SPECjbb 2015)
OLTP database (тест HammerDB)
Давайте взглянем на результаты тестирования производительности с точки зрения гостевой системы и ее приложений:
1. Число выдаваемых IOPS в зависимости от количества снапшотов для виртуальной машины (Random I/O):
В этом тесте и в последующих мы увидим, что снапшоты не влияют на производительность хранилищ VVols - такова природа этих хранилищ. А вот с VMFS и vSAN мы видим, что производительность падает, для VMFS - в три раза уже с первого снапшота, для vSAN - с третьего.
2. Для последовательного чтения vSAN ведет себя значительно лучше, а вот на VMFS производительность уже с первого снапшота падает в 2.5 раза, и дальше только хуже:
3. Для обработки запросов SPECjbb во всех трех случаях снапшоты не оказывали влияния на производительность:
4. По количеству транзакций в секунду тест HammerDB тоже показывает падение производительности хотя бы с одним снапшотом почти в 3 раза:
Интересно, что для хранилищ vSAN со снапшотами просадки по производительности для теста HammerDB нет.
5. Интересна также производительность гостевых ОС при соазднии и при удалении снапшотов:
Как мы видим, на VMFS критичен первый снапшот, и исходная производительность возвращается виртуальной машине только с удалением последнего снапшота. На vSAN производительность уменьшается и увеличивается постепенно, с изменением количества снапшотов.
Для больших блоков ввода вывода страдает только VMFS при последовательном чтении:
При последовательной записи больших блоков снапшоты влияют только на VMFS (при этом, только первый):
Ну и в заключение VMware приводит такую табличку потерь производительности для виртуальных машин с одним снапшотом:
Итак, очевидные выводы:
Снапшоты - зло. Особенно для VMFS и иногда для vSAN.
Особенное зло снапшотов проявляется для случайного чтения (Random reads), хотя и для последовательного все далеко не так хорошо.
Хранилищам VVol все равно на снапшоты, производительность не падает.
Зло, как правило, именно первый снапшот, дальше уже не так важно, сколько их, но производительность продолжает падать.
При удалении снапшотов производительность ВМ возвращается к исходному уровню.
Как вы знаете, в кластере отказоустойчивости VMware HA есть Primary и Secondary хосты серверов ESXi. Первые отвечают за управление кластером и восстановление виртуальных машин, а вторые – только за исполнение операций и рестарт ВМ. Недавно мы, кстати, писали о том, как сделать хост VMware vSphere Primary (он же Master) в кластере HA, а сегодня расскажем о том, какие события происходят на этих хостах в случае отказа хоста (именно полного отказа, а не при недоступности, например, его в сети).
Как пишет Дункан Эппинг, если отказывает хост Secondary, то происходят следующие вещи, начиная с времени T0:
T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
T+3 секунды – хост Primary начинает отслеживать хартбиты на хранилище в течение 15 секунд
T+10 секунд – хост помечается как unreachable и Primary хост начинает пинговать его Management Network (постоянно в течение 5 секунд)
T+15 секунд – если на датасторе на настроены хартбиты, то хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
Либо если настроены хартбиты, но их нет, то через T+18 секунд хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин
В случае с отказом Primary хоста все немного дольше и сложнее, так как кластеру нужно определиться с новым Primary узлом и восстановить/перенастроить себя. Тут происходит следующее:
T0 – происходит отказ хоста и недоступность виртуальных машин (например, отключение питания, завис ESXi и т.п.)
T+10 секунд – начинаются выборы нового Primary хоста в кластере
T+25 секунд - выбор хоста Primary сделан и он читает список виртуальных машин, а также ждет, пока Secondary хосты сообщат о своих виртуальных машинах
T+35 секунд – старый хост Primary помечается как unreachable
T+50 секунд – хост помечается как «мертвый», и начинается процесс восстановления виртуальных машин согласно списку нового Primary
Надо помнить, что это все времена начала процессов, но не их завершения. Например, если процесс восстановления начинается через 15 секунд, то нужно время, чтобы найти место для виртуальной машины на новом хосте и запустить ее там – а вот это время рассчитать невозможно.
Многие администраторы VMware vSphere 7 после выхода обновления Update 2 этой платформы были удивлены, что многие настройки пропали из основного конфигурационного файла esx.conf. Мы уже рассказывали о configstore – хранилище настроек, к которому можно получить доступ через импорт и экспорт настроек в формате JSON.
Дункан Эппинг показал на примере виртуального коммутатора vSwitch, как можно работать с configstore и хранящимися там настройками. Например, вам требуется сменить имя виртуального коммутатора. Вы можете посмотреть его текущие сетевые настройки командой:
configstorecli config current get -c esx -g network_vss -k switches
Ну а экспортировать эти настройки в JSON-файл можно командой:
configstorecli config current get -c esx -g network_vss -k switches > vswitch.json
Далее вы просто открываете этот файл в текстовом редакторе и изменяете имя коммутатора c vSwitch0 на нужное:
Потом получившийся файл нужно обратно импортировать в configstore:
configstorecli config current set -c esx -g network_vss -k switches -i vswitch.json --overwrite
После этого вы увидите изменения в vSphere Client:
Также Дункан записал видео, в котором показан этот процесс:
На сайте проекта VMware Labs вышло очередное обновление - VMware ESXi Arm Edition
версии 1.4. Напомним, что эта специальная версия версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О версии 1.3 мы писали в начале апреля вот тут.
Давайте посмотрим, что нового в июньской версии VMware ESXi ARM Edition 1.4:
Улучшенная технология виртуализации PMU (Performance Monitoring Unit)
Исправлены проблемы с виртуальным устройством AHCI для некоторых ОС ACPI
Улучшена работа с обработкой времени
Экспериментальная поддержка NVIDIA Tegra Xavier AGX и NVIDIA Tegra Xavier NX (PCIe, USB, NVMe, SATA). Это что-то типа вот такой штуки:
Экспериментальная поддержка серверов 2P Ampere на базе Altra. Это вот такие штуки:
Увеличенная производительность виртуальных машин для мультисокетных серверов на базе ARM
Исправлены проблемы с виртуальным NVMe в UEFI для некоторых ОС
Улучшена виртуализация контроллера прерываний
Улучшена общая производительность гипервизора и техник виртуализации в целом
Улучшена совместимость с ядрами Linux для новых ОС
Исправлены проблемы стабильности USB-устройств, особенно для сетевых адаптеров на базе RTL8153 для платформ Raspberry Pi и Tegra Xavier
Обновлена документация для ESXi-Arm Fling, Raspberry Pi, Ampere Altra, NVIDIA Xavier AGX и NVIDIA Xavier NX (опции доступны в комбобоксе при скачивании продукта)
Загрузить VMware ESXi ARM Edition 1.4 и документацию можно по этой ссылке.
На сайте проекта VMware Labs обновился нативный USB-драйвер для ESXi, который необходим для сетевых адаптеров серверов, подключаемых через USB-порт. Такой адаптер, например, можно использовать, когда вам нужно подключить дополнительные Ethernet-порты к серверу, а у него больше не осталось свободных PCI/PCIe-слотов.
По умолчанию отключено сканирование шины USB (расширенная настройка usbBusFullScanOnBootEnabled=0) - это позволяет предотвратить розовый экран смерти (PSOD) для пользователей, использующих несколько сетевых карт на USB-портах
Таблица поддерживаемых чипсетов и адаптеров на сегодняшний день выглядит так:
Загрузить USB Network Native Driver for ESXi для VMware vSphere 7.0 Update 1 и Update 2 можно по этой ссылке.
На сайте Вильяма Лама есть специальный раздел, посвященный вложенной виртуализации (Nested Virtualization) на базе гипервизора VMware ESXi. В частности, Вильям делает сборки ESXi, которые уже подготовлены к использованию в качестве виртуальных машин как виртуальные модули (Virtual Appliances) в формате OVA. Это может понадобиться для тестовых сред, когда вам нужно развернуть большую инфраструктуру и сделать полноценный кластер, а в распоряжении есть только 1-2 физических сервера.
Также обратите внимание на наш пост о библиотеке Content Library с шаблонами виртуальных модулей Nested ESXi от Вильяма. Адрес для подписки на эту библиотеку следующий:
Если вы часто имеете дело с технической поддержкой VMware, то знаете, что довольно часто требуется собирать с хостов VMware ESXi дампы. Нередко администраторы настраивают удаленную отсылку дампов на сервер VMware vCenter Server Appliance (vCSA). По умолчанию размер раздел для дампов на нем равен 2 ГБ, что может оказаться мало, если инфраструктура у вас большая.
Вильям Лам задался этим вопросом и вспомнил, что есть такая настройка Repository max size в разделе ESXi Dump Collector для старого клиента vSphere Web Client:
Между тем, в новый vSphere Client на базе HTML 5 эту настройку не перенесли. Поэтому если вы используете VMware vCSA версий 6.7 или 7.0 с новым клиентом, то вам нужно открыть файл /etc/sysconfig/netdumper и изменить там следующий параметр:
NETDUMPER_DIR_MAX_GB
Максимальный его размер может составлять 10GB.
После изменения размера раздела для дампов нужно перезапустить сервис дампера. На vCSA 7 делается одной командой:
Вильям Ламм написал интересную статью про USB-устройства на хосте VMware ESXi, когда нужно использовать некоторые устройства как хранилища, а некоторые - для проброса в виртуальные машины. При этом, в рамках данной методики, не нужно останавливать USB Arbitrator Service на хосте.
Итак, для начала выводим список доступных USB-интерфейсов на сервере:
esxcli hardware usb passthrough device list
У Вильяма в списке 2 USB-хранилища (их пары VendorId:ProductId имеют значения 90c:2000 и 90c:1000):
Для второго устройства можно отключить именно функции проброса USB (passthrough), чтобы устройство не могло быть презентовано виртуальной машине. Для этого выполняем такую команду:
esxcli hardware usb passthrough device disable -d 2:7:90c:1000
После этого будет вот такая картина:
Далее уже можно подключить это устройство хранения к хосту ESXi, чтобы использовать его для создания VMFS-томов. Процедура описана вот тут, посмотрим на нее вкратце.
Сначала добавляем расширенную настройку (Advanced Setting) на хосте ESXi, чтобы он принимал SSD-диски, подключенные к USB:
esxcli system settings advanced set -o /Disk/AllowUsbClaimedAsSSD -i 1
Теперь нужно создать SATP-правило, которое помечает наше USB-устройство как SSD-диск. Для этого нужно получить имя устройства с помощью команды:
vdq -q
Затем создаем переменную с именем устройства, например:
Теперь устройство можно использовать как SSD-диск для vSAN или VMFS. Если хотите использовать его для vSAN, то нужно включить соответствующую расширенную настройку командой:
esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1
После этого вы сможете увидеть данное устройство в выводе команды vdq -q как совместимое для vSAN, на котором можно создавать дисковые группы:
Если же вы хотите использовать этот SSD-диск как хранилище VMFS, то нужно сначала создать том, чтобы он был виден в интерфейсе vSphere Client.
Дункан Эппинг написал интересный пост о том, что в кластере VMware HA есть возможность сделать хостам ESXi такую настройку, чтобы они выбирались как Primary при конфигурации/реконфигурации кластера. Это может оказаться полезным, например, в растянутом (Stretched) кластере, когда вам важно, чтобы Primary-хосты находились на основной площадке с целью ускорения процесса восстановления после сбоя (речь идет о 2-3 секундах в большинстве случаев, но для некоторых инфраструктур это может быть критично).
Пост этот актуален еще и потому, что настройки несколько изменились, начиная с VMware vSphere 7 Update 1, поэтому информация об этом может быть полезна для администраторов.
Прежде всего, в статье VMware KB 80594 рассказывается о том, какие настройки были изменены в механизме VMware FDM (он же HA). Самое главное, что до vCenter 7 Update 1 настройки хранились в файле /etc/opt/vmwware/fdm/fdm.cfg, теперь же они переехали в ConfigStore, работать с которым нужно путем импорта и экспорта json-файлов конфигурации.
Вот, кстати, интересующая нас табличка с изменениями параметров Advanced Settings в FDM:
Нас здесь интересует настройка node_goodness, большое численное значение которой и определяет, будет ли данный узел выбран как Primary (ранее в HA он также назывался Master).
Итак, Дункан показывает, как можно экспортировать расширенные настройки из ConfigStore:
configstorecli config current get -g cluster -c ha -k fdm
{
"mem_reservation_MB": 200,
"memory_checker_time_in_secs": 0
}
Все это можно также экспортировать в json-файл командой:
configstorecli config current get -g cluster -c ha -k fdm > test.json
Далее добавляем в этот json параметр node_goodness с большим значением, например, 10000000:
Недавно мы писали о новой службе Virtual Machine Service, которая появилась в последней версии VMware vCenter 7 Update 2a, вышедшей несколько дней назад. Через некоторое время компания VMware обновила и свою основную платформу виртуализации до версии ESXi 7 Update 2a, обновив таким образом оба компонента VMware vSphere 7 до Update 2a.
Основным нововведением ESXi 7 Update 2a (он же билд 17867351) является исправление бага с апгрейдом с прошлых версий vSphere. Пользователи, у которых был настроен кастомный бейслайн vSphere Lifecycle Manager (vLCM), после апгрейда получали вот такую ошибку (для билда 17630552 в комплекте Update 2):
Failed to load crypto64.efi
Теперь старый билд Update 2 был убран из репозитория, а все обновления будут уже до версии 2a.
Также в U2a появилось немало нововведений для VMware vSphere with Tanzu:
Supervisor Cluster
Управление ресурсами Kubernetes через Virtual Machine Service. Об этом мы подробно писали тут.
Самостоятельное создание пространств имен со стороны разработчиков (по шаблону, заданному администратором, который определяет лимиты и права доступа).
Tanzu Kubernetes Grid Service for vSphere
Сервер Kubernetes metrics-server включен по умолчанию. Основные параметры узлов и Pod'ов можно смотреть командой kubectl top.
Система обработки webhooks теперь поддерживает dry-run mode. Теперь такие популярные утилиты, как, например, Terraform Kubernetes provider можно интегрировать с Tanzu Kubernetes Grid Service.
Кастомные классы виртуальных машин (Virtual Machine Classes), которые потребляются через службы VM Service. Это позволяет пользователям выделить различные параметры CPU и памяти, которая выделена виртуальным машинам в кластере Tanzu Kubernetes Cluster.
Обновить инфраструктуру на vSphere 7 Update 2a можно следующими командами в консоли:
На сайте проекта VMware Labs вышло обновление VMware ESXi Arm Edition 1.3. Напомним, что эта версия гипервизора VMware предназначена для процессоров ARM (на их базе построена, например, архитектура Raspberry Pi, а также многие IoT-устройства). О прошлом релизе этой платформы мы писали вот тут.
Давайте посмотрим, что нового в ESXi для ARM:
Улучшенная аппаратная совместимость (множество исправлений ошибок и улучшений по поддержке железа).
Добавлена экспериментальная поддержка архитектуры Ampere Altra (только для односокетных систем (подробнее тут).
Поддержка ACPI для виртуальных машин.
Поддержка загрузки через NVMe и PVSCSI в EFI.
Добавлен воркэраунд для загрузки с ISO для некоторых ARM-серверов.
Пофикшена проблема с падением современных ОС при работе на системах на базе Neoverse N1.
Улучшен механизм виртуализации контроллера прерываний для гостевых ОС.
Улучшены средства работы с виртуальными PMU.
Улучена поддержка big endian.
Скачать установочный образ VMware ESXi Arm Edition 1.3 можно по этой ссылке. Помните, что апгрейд с предыдущей версии не поддерживается - надо устанавливать заново.
Небольшое обзорное видео установки ESXi Arm Edition:
Многие администраторы VMware vSphere знают, что для серверов ESXi установлен лимит одновременных миграций vMotion (входящих и исходящих) на один хост = 8 штук. Многие интересуются, а почему именно восемь? Ведь если бы увеличить это число, то виртуальные машины с хоста смогут быстрее эвакуироваться во время проведения планового обслуживания и обновления хостов при их переводе в режим обслуживания (maintenance mode).
Для разъяснения этого VMware написала интересную статью, где рассматриваются результаты тестирования миграций vMotion виртуальных машин при разных значениях параметра, ограничивающего число одновременных миграций.
Лимит на vMotion установлен со стороны сервера vCenter. Он считает ограничения следующим образом. Если на хосте 2 физических сетевых карты 40GbE NIC, выделенных под vMotion, то он считает каждую из них как емкость из 8 слотов с точки зрения миграций, а совокупная емкость хоста равна 16 слотам, из которых 2 тратится на каждую операцию vMotion:
В VMware сделали тестирование производительности одновременных миграций vMotion на хостах ESXi в рамках тестового стенда (он описан в статье), где число Concurrent vMotions регулировали с помощью следующего расширенного параметра vCenter:
config.vpxd.ResourceManager.costPerVmotionESX6x
По умолчанию он равен 2, что означает, что из 16 слотов хоста на каждую vMotion будет тратиться пара слотов, а суммарно будет возможно сделать 8 миграций одновременно. Если поставить это значение в 4, то, соответственно, будет выполняться 4 одновременных миграции (16/4=4).
Надо отметить, что настройка этого параметра не поддерживается со стороны VMware, поэтому не удивляйтесь, что если при его изменении у вас что-то пойдет не так.
Таким вот образом, под разными нагрузками на ВМ, проводили тестирование как восьми одновременных миграций:
Так и четырех:
Если миграции стоят в очереди, то для них отображается статус "Resources currently in use by other operation".
Результаты получились следующими (по оси Х изменяли объем оперативной памяти машин):
То есть восемь одновременных миграций с точки зрения эвакуации всех машин с хоста проигрывают рабочему процессу с четырьмя vMotion.
Аналогично возрастало и среднее время миграции:
Если говорить об использовании памяти, то видно что при 4 одновременных миграциях было передано на 10% меньше страниц памяти, что говорит о более эффективном ее использовании:
Для второго теста выбрали утилиту DVD Store, которую использовали для 2 типов соединений - 10 GbE и 100 GbE:
И здесь тоже результаты получились в пользу 4 одновременных миграций. Та же картина была и для 100 GbE-соединения:
Таким образом, получается, что при большом увеличении числа одновременных миграций vMotion на хосте, удельная производительность каждой такой миграции будет падать.
VMware просто сфокусировалась тут на более эффективном использовании канала для каждой из миграций, поэтому число одновременных vMotion имеет уже не такое влияние, как это было раньше. Поэтому данный параметр и не увеличивается в таблице максимумов от релиза к релизу VMware vSphere.