vSphere HA отслеживает доступность ESXi-хостов в кластере и при подтверждённом отказе пытается перезапустить затронутые виртуальные машины на оставшихся узлах. DRS выбирает размещение VM и при необходимости балансирует нагрузку миграциями vMotion. Для обеих функций нужны совместимые хосты, работоспособные сети и хранилище, запас ресурсов на отказ узла, а также права на функции в используемом предложении VMware/Broadcom, лицензии или подписке.
Что делают HA, DRS, vMotion и резервное копирование
| Механизм | Событие или задача | Результат | Чего не обеспечивает |
|---|---|---|---|
| Высокая доступность vSphere HA | Отказ или недоступность ESXi-хоста в пределах сценариев, которые HA может подтвердить | Попытка зарегистрировать и запустить VM на доступном хосте кластера | Непрерывную работу VM, отсутствие простоя, защиту от сбоя приложения, повреждения данных или отказа общего хранилища |
| DRS | Неравномерное потребление CPU и памяти, начальное размещение VM, правила размещения | Рекомендация либо автоматическое размещение и миграция VM между хостами | Аварийный перезапуск при отказе хоста, резервную копию, защиту приложения |
| vMotion | Плановая миграция включённой VM между совместимыми хостами | Перенос работающей VM без выключения гостевой ОС; при переключении возможна краткая пауза | HA, репликацию данных, перенос любой VM без ограничений |
| Резервн ое копирование | Удаление, повреждение, ошибка приложения, необходимость восстановить прошлое состояние | Восстановление из созданной и проверенной копии в рамках выбранных RPO и RTO | Автоматический запуск VM на другом хосте и балансировку ресурсов |
HA, DRS и vMotion обычно работают совместно, но не взаимозаменяемы. DRS использует vMotion как один из механизмов перемещения нагрузки; HA использует кластерную информацию, чтобы после отказа хоста попытаться запустить VM в другом месте. Вопросы внешних копий и восстановления относятся к отдельной стратегии резервного копирования: ни HA, ни снимок виртуальной машины не являются её заменой.
Проверяйте функции для своего релиза
Набор HA, DRS, vMotion и связанных политик зависит от версии vSphere, приобретённого предложения VMware/Broadcom, лицензии или подписки. Перед изменениями сверяют официальную матрицу возможностей и документацию именно используемого релиза, а совместимость vCenter Server и ESXi — в VMware Product Interoperability Matrix. Названия экранов, статусов, режимов и пунктов интерфейса vSphere Client зависят от версии vCenter Server, ESXi и firmware; ниже приведён порядок действий, а не универсальный путь по меню.
Что происходит при отказе, изоляции и разделении сети
При отказе исходного хоста HA не переносит исполняющуюся VM в её текущем состоянии. После обнаружения и подтверждения отказа он пытается запустить VM заново на другом доступном хосте, где доступны её файлы и ресурс ы. Поэтому это перезапуск, а не миграция без простоя: незавершённые операции гостевой ОС или приложения могут быть прерваны.
Сценарии, которые важно различать при настройке HA
| Ситуация | Что видит кластер | Возможная реакция HA | Что проверить |
|---|---|---|---|
| Отказ хоста | Хост перестаёт отвечать по кластерным контрольным сигналам и не подтверждает свою активность | HA пытается перезапустить затронутые VM на других хостах | Доступность общих файлов VM, свободные CPU и память, состояние агентов HA |
| Изоляция хоста | Хост теряет связь с другими хостами и адресами проверки изоляции, но может продолжать выполнять VM | Зависит от политики Host Isolation Response: VM могут остаться включёнными либо быть выключены или остановлены с последующим восстановлением в кластере | Выбранную реакцию на изоляцию, связность management-сети, доступ к datastore, состояние блокировок файлов VM и адреса проверки изоляции |
| Network partition | Кластер распадается на группы хостов, которые не видят друг друга по управляющей сети | Поведение зависит от того, какая часть кластера сохраняет доступ к хранилищу и как HA определяет состояние хостов | Топологию management-сети, доступ к datastore и журнал событий HA |
| Недоступность datastore | Хост или группа хостов теряет доступ к хранилищу с файлами VM | Не всегда означает отказ хоста; возможность перезапуска зависит от типа и доступности хранилища другим хостам | Путь доступа к хранилищу, состояние массива или сети хранения, доступность файлов VM |
Datastore Heartbeat помогает HA отличать потерю связи по management-сети от полной недоступности хоста: хост отмечает активность на общем datastore. Это дополнительный сигнал, а не замена устойчивой сети управления или доступного хранения. Точное решение HA при частичной сетевой аварии определяется алгоритмами и настройками целевого релиза; его следует сверять с официальным руководством VMware для используемой версии.
Изоляция не равна отказу питания
Не выбирайте Host Isolation Response по принципу «остановить всегда» или «оставить всегда». При отключённой реакции на изоляцию VM может продолжить работу на изолированном ESXi, но остаться недоступной через сеть приложения и не быть перезапущенной на другом узле. Реакции Shut down или Power off сначала завершают работу исходного экземпляра, после чего HA может попытаться запустить VM в доступной части кластера; это означает прерывание сервиса. Штатные механизмы HA и блокировки файлов VM предназначены для предотвращения одновременного включения одного экземпляра VM на двух хостах. Отдельный прикладной fencing всё равно учитывают для многовузловых приложений и СУБД. Политику выбирают по документации целевого релиза с учётом доступа к datastore и сетям приложения.
Предварительная проверка кластера для VMware HA и DRS
Подготовьте инфраструктуру до включения функций
Выполните проверки до включения HA и DRS на продуктивных VM. Первичное развёртывание VCSA и добавление хостов описаны в статье VMware vSphere и vCenter Server: установка VCSA и добавление хостов.
- 1Проверьте состав и совместимость хостовВ одном кластере должны быть несколько совместимых ESXi-хостов, управляемых vCenter Server. Сверьте версии ESXi и vCenter Server в VMware Product Interoperability Matrix, совместимость серверов и адаптеров с Hardware Compatibility List, а также требования к смешанным версиям при обновлении кластера. Ожидаемый результат — каждый хост поддерживается целевым релизом и может состоять в кластере. При несовпадении версий или неподдерживаемом оборудовании не включайте автоматизацию: сначала спланируйте обновление либо замену компонента.
- 2Проверьте management-сеть и агенты HAКаждый хост должен устойчиво обмениваться управляющими сигналами с другими хостами кластера через management network. Проверьте отсутствие периодических потерь связи, корректные VLAN и uplink, доступность требуемых адресов проверки изоляции и отсутствие одиночной точки отказа там, где архитектура требует резервирования. После включения HA состояние агентов на всех хостах должно быть нормальным, без ошибок конфигурации. Если хост периодически становится disconnected или выдаёт предупреждение HA agent, сначала устраняют сеть и агент, а не меняют реакцию на изоляцию.
- 3Подтвердите доступность хранения для восстановленияФайлы VM должны быть доступны тому хосту, на котором HA будет её запускать. В типичной архитектуре это общее поддерживаемое хранилище; в распределённых архитектурах применимость зависит от используемого типа хранения и политики. Убедитесь, что datastore видны необходимым хостам, имеют свободное место и подходят для datastore heartbeat. Ожидаемый результат — доступ к файлам каждой защищаемой VM сохранится после потери одного хоста. Локальный datastore од ного ESXi обычно не позволяет запустить такую VM на другом узле без отдельной поддерживаемой архитектуры.
- 4Рассчитайте запас N+1Смоделируйте потерю самого нагруженного или наиболее ёмкого хоста: оставшиеся узлы должны вместить VM, которые должны восстановиться, с учётом их фактической потребности, резервирований и критичных пиков. Не ориентируйтесь только на сумму выделенных vCPU и памяти. Ожидаемый результат — определено, какие VM могут быть перезапущены после отказа и при каких ограничениях. Если запаса нет, добавьте ёмкость, уменьшите нагрузку, измените приоритеты или явно примите риск неполного восстановления. Детальный расчёт относится к статье Как спроекти ровать виртуальную инфраструктуру для продакшена и 1С.
- 5Подготовьте сеть и совместимость для vMotionДля миграций DRS каждому участвующему хосту требуется VMkernel-интерфейс с включённым сервисом vMotion и связность с VMkernel-интерфейсами других хостов. Проверьте маршрутизацию либо L2-связность по выбранной архитектуре, MTU на всём пути при использовании увеличенного MTU, пропускную способность и резервирование физических путей. Также проверьте совместимость CPU; для хостов разных поколений одного производителя может потребоваться EVC. При ошибке совместимости CPU, сети или хранилища DRS не сможет автоматически переместить часть либо все VM.
- 6Найдите VM с ограничениями миграцииПроверьте подключённые физические или PCIe-устройства, passthrough, отдельные типы виртуальных устройств, особые параметры VM, привязки к хосту и доступность требуемого datastore на цели. Для таких VM vMotion может быть недоступен или ограничен. Ожидаемый результат — составлен список исключений и для каждой VM определено допустимое размещение. Подробности диагностики vMotion и других видов миграции приведены в статье Миграция виртуальных машин: live migration, V2V и P2V.
Включите HA и настройте Admission Control
Admission Control не создаёт ресурсы, а контролирует, может ли кластер сохранить заданную способность к восстановлению VM. В зависимости от релиза доступны политики, основанные на допустимом числе отказов хостов, доле ресурсов кластера или иной модели резервирования. Конкретный набор политик, расчёт и отображаемые значения нужно сверять с документацией используемого релиза.
Настройте HA без ложного запаса мощности
- 1Включите HA на подготовленном кластереВ настройках кластера включите vSphere HA и дождитесь, пока агенты будут настроены на всех хостах. Проверьте задачи и события: ожидаемый результат — нет ошибок установки или конфигурации HA agent, а кластер не сообщает о недоступном heartbeat или хранилище. Если агент не настраивается, проверьте DNS, management network, доступность vCenter и сообщения конкретного хоста.
- 2Выберите модель Admission Control по целевому отказуЗафиксируйте сценарий, например переживание отказа одного хоста, и выберите доступную в вашем релизе политику, соответствующую этому сценарию. Сопоставьте показание зарезервированной или допустимой ёмкости с расчётом N+1 и критичностью VM. Ожидаемый результат — политика не допускает размещения, которое разрушит принятый запас. Если Admission Control блокирует запуск VM, не отключайте его автоматически: выясните, вызвана ли проблема реальной нехваткой ёмкости, большими резервированиями или ошибочной моделью отказа.
- 3Настройте приоритеты перезапуска VMНазначьте HA restart priority для VM по порядку восстановления сервисов: например, инфраструктурные зависимости раньше прикладных компонентов, если это соответствует архитектуре приложения. Приоритет влияет на порядок попыток запуска после события HA, но не резервирует CPU и память, не гарантирует успешную загрузку гостевой ОС и не подтверждает готовность приложения принимать запросы. Ожидаемый результат — критичные VM имеют осмысленный порядок, а обычные VM не получают максимальный приоритет без причины.
- 4Выберите реакцию на изоляцию после анализа рискаСопоставьте Host Isolation Response со схемой хранилища, сетей и прикладного fencing. Оставление VM включённой снижает риск лишнего прерывания при ложной изоляции, но может задержать восстановление на другом узле. Остановка или выключение VM может позволить перезапуск в кластере, но прерывает работу на и сходном хосте. Ожидаемый результат — выбранная политика документирована для конкретной архитектуры и не конфликтует с возможным доступом изолированного хоста к данным.
- 5Включайте VM Monitoring только для подходящих VMVM Monitoring использует heartbeat VMware Tools и активность ввода-вывода, чтобы выявлять зависание гостевой ОС и выполнять reset VM. Это отдельная функция HA: она не проверяет работоспособность прикладного сервиса и не заменяет мониторинг приложения. Сначала убедитесь, что VMware Tools установлены и штатно работают, затем включите мониторинг для тестовой или некритичной VM и проверьте события. При ложных срабатываниях анализируйте причины и параметры чувствительности, а не оставляйте аварийный reset неконтролируемым.
Отключённый Admission Control меняет риск, а не увеличивает кластер
При отключении Admission Control vSphere может разрешить запуск дополнительных VM, но после отказа хоста ресурсов для их размещения может не оказаться. Тогда HA способен запустить только часть VM либо оставить часть выключенной. Резервирования, лимиты ресурсов, доли ресурсов и пулы ресурсов также могут менять фактическую доступную ёмкость и результат восстановления.
Включите DRS и выберите степень автоматизации
Distributed Resource Scheduler анализирует потребление CPU и памяти, доступные ресурсы, правила размещения и возможности миграции. При создании или включении VM DRS помогает с начальным размещением; во время работы он может рекомендовать либо выполнять vMotion для выравнивания нагрузки. DRS не является инструментом тонкой настройки производительности VM: причины CPU Ready, дефицита памяти и задержек хранилища разбирают отдельно в статье Производительность виртуализации: ресурсы VM и поиск узких мест.
Настройте DRS поэтапно
- 1Подтвердите, что vMotion возможен между хостамиДо автоматизации выполните контролируемую миграцию некритичной VM между парами хостов, если это допускает согласованное окно. Проверьте задачу миграции, доступность VM после неё и отсутствие предупреждений о CPU, VMkernel-сети, datastore или устройствах. Ожидаемый результат — VM может мигрировать между теми хостами, которые DRS будет использовать. Если миграция не проходит, устраните первопричину; DRS не исправит несовместимость.
- 2Начните с ручного режимаВ режиме Manual DRS формирует рекомендации для начального размещения и последующих миграций, а администратор подтверждает их. Проверьте, как ие VM и хосты предлагаются, не нарушают ли рекомендации технологические и прикладные ограничения. Ожидаемый результат — рекомендации объяснимы и выполнимы. Если миграция недопустима для VM, оформите исключение или правило, а не игнорируйте рекомендации постоянно.
- 3Проверьте порог миграцийВ доступных для релиза параметрах DRS задайте осторожный migration threshold: более агрессивная настройка допускает больше миграций, а более консервативная — меньше перемещений и более слабую реакцию на дисбаланс. Ожидаемый результат — число миграций соответствует характеру нагрузки и не создаёт лишнюю нагрузку на сеть и хранилище. Изменяйте порог после наблюдения за задачами и метриками, по одному параметру за раз.
- 4Выберите частичную или полную автоматизациюЕсли используемый релиз предлагает режим Partially Automated, в нём начальное размещение выполняется автоматически, а миграции работающих VM остаются рекомендациями для администратора. В режиме Fully Automated DRS автоматически выполняет и начальное размещение, и допустимые vMotion. Перед переходом к полной автоматизации убедитесь, что рекомендации стабильно корректны, а ограничения VM оформлены правилами или исключениями. Названия режимов, доступные параметры и переопределения на уровне отдельных VM сверяйте с документацией используемого релиза.
Настройте affinity и anti-affinity без конфликтов
Affinity Rule задаёт совместное или раздельное размещение VM, а также привязку VM к группам хостов. Правила бывают обязательными или предпочтительными в зависимости от доступных типов и релиза. Они прежде всего ограничивают решения DRS и размещение VM; они не заменяют HA restart priority и не добавляют ресурсов для восстановления.
Как не смешивать политики размещения и восстановления
| Настройка | На что влияет | Типичный риск |
|---|---|---|
| HA restart priority | Очередность попыток запуска VM после события HA | Ожидание, что высокий приоритет создаст ресурсы или обеспечит готовность приложения |
| Host Isolation Response | Судьбу VM на изолированном хосте в предусмотренном политикой сценарии | Выбор без учёта доступа изолированного хоста к данным |
| VM Monitoring | Аварийный reset VM при признаках зависания гостевой ОС | Использование как проверки прикладного сервиса |
| VM-VM affinity/anti-affinity | Совместное либо раздельное размещение VM | Обязательное anti-affinity при недостаточном числе хостов |
| VM-Host rule | Допустимые или предпочтительные хосты для VM | Исключение всех хостов, на к оторых HA могла бы перезапустить VM |
Проверьте правила размещения
- 1Опишите зависимые и резервируемые компонентыДля каждой пары или группы VM определите, должны ли они находиться вместе из-за задержек либо должны быть разнесены для переживания отказа одного хоста. Например, две независимые реплики приложения обычно не следует жёстко закреплять за одним ESXi. Ожидаемый результат — у каждого правила есть понятная причина, владелец и допустимое поведение при отказе.
- 2Пр едпочитайте мягкие ограничения, когда это допустимоИспользуйте предпочтительное правило, если нарушение размещения на время отказа лучше, чем невозможность запуска VM. Обязательное правило выбирайте только при реальном техническом или лицензионном требовании. Ожидаемый результат — кластер сохраняет возможность восстановить VM при сокращении числа доступных хостов.
- 3Проверьте правила в сценарии N+1Сопоставьте все правила с потерей одного хоста: каждая критичная VM должна иметь хотя бы один допустимый целевой хост, а anti-affinity не должна требовать больше работающих хостов, чем остаётся после отказа. Ожидаемый результат — в состоянии кластера нет конфликтов правил и неприменимых ограничений. Если правило блокирует восстановление, измените его тип, состав групп или план ёмкости.
Проверьте готовность HA и DRS до эксплуатации
Проведите контролируемую проверку
- 1Проверьте состояние кластераПросмотрите состояние HA и DRS, агентов HA на хостах, ошибки конфигурации, предупреждения сети и хранилища, datastore heartbeat, доступность vMotion и нарушения affinity-правил. Ожидаемый результат — нет предупреждений, которые указывают на недоступный хост, незащищённую VM, неработающий heartbeat, неподдерживаемую миграцию или дефицит резервной ёмкости. Каждое предупреждение разберите по событию и задаче, а не скрывайте его.
- 2Проверьте плановую эвакуациюВ согласованное окно переведите один хост в режим обслуживания и проследите, как DRS либо администратор эвакуирует допустимые VM. Ожидаемый результат — мигрируемые VM уходят на совместимые хосты, а немигрируемые исключения явно видны. Этот тест подтверждает плановую эвакуацию и vMotion, но не имитирует отказ хоста и не доказывает аварийный перезапуск HA.
- 3Проверьте рекомендации и автоматизацию DRSНа некритичной нагрузке проверьте начальное размещение и, если выбран автоматический режим, историю выполненных миграций. Ожидаемый результат — DRS не нарушает правила и не пытается переместить VM с известными ограничениями. При неожиданной миграции проверьте потребление ресурсов, migration threshold, правила VM и доступность цели.
- 4Планируйте тест HA только как аварийный сценарийПроверку реакции HA проводите только по документированному VMware сценарию, в согласованное окно, на некритичной или тестовой VM, с подтверждённым восстановлением приложения и планом отката. Не отключайте рабочий ESXi-хост, питание или management-сеть в продуктивном кластере ради эксперимента. Ожидаемый результат теста — зафиксированы время обнаружения, событие HA, хост перезапуска, порядок VM и работоспособность тестового сервиса после загрузки.
Проблема
HA сообщает о недостаточной ёмкости или не может гарантировать восстановление
Возможные причины
- Недостаточно CPU или памяти на оставшихся хостах
- Завышенные резервирования VM или пулов ресурсов
- Жёсткие VM-Host либо anti-affinity правила
- Admission Control отключён или настроен не под реальный сценарий
Решение
Сначала пересчитайте N+1 по критичным VM и их резервированиям, затем добавьте ёмкость, уменьшите гарантированные резервирования там, где это безопасно, или пересмотрите правила размещения. После каждого изменения убедитесь, что политика Admission Control снова отражает целевой отказ.
Как избежать
Пересматривайте запас мощности при добавлении VM, изменении резервирований и вы воде хостов в обслуживание.
Проблема
DRS не мигрирует VM или выдаёт неприменимые рекомендации
Возможные причины
- Нет связности VMkernel-сети vMotion
- CPU несовместимы или EVC не соответствует составу кластера
- Datastore недоступен целевому хосту
- VM использует неподдерживаемое устройство или специальную настройку
- Правила affinity/anti-affinity исключают все цели
Решение
Проверьте журнал конкретной задачи vMotion и устраните указанную первопричину: сеть, CPU/EVC, доступ к datastore, устройство VM или правило размещения. Затем повторите миграцию на некритичной VM и только после этого возвращайте автоматизацию DRS.
Как избежать
Проверяйте миграцию после добавления нового типа хоста, изменения сети, хранилища, EVC и аппаратных настроек VM.
Проблема
Хост периодически изолируется или появляются предупреждения heartbeat
Возможные причины
- Потери пакетов или неверная VLAN в management-сети
- Отказ uplink, коммутатора или маршрута до адресов проверки
- Проблемы с доступом к общему datastore
- Несогласованная сетевая топология между хостами
Решение
Локализуйте проблему по времени событий: проверьте физические uplink, VLAN, сетевые журналы, VMkernel-интерфейсы, доступность datastore и адресов проверки изоляции. Не компенсируйте сетевую неисправность отключением HA или сменой Host Isolation Response без анализа.
Как избежать
Разделяйте и резервируйте потоки управления и хранения в соответствии с требованиями архитектуры; изменения виртуальной и физической сети выполняйте контролируемо.
Термины в статье
- Виртуальная машина
- Изолированная вычислительная среда с виртуальными процессорами, памятью, дисками и сетевыми адаптерами, в которой под управлением гипервизора работает гостевая ОС.
- Высокая доступность
- Высокая доступность (HA) — способность системы сохранять сервис или автоматически восстанавливать его с минимальным простоем при отказе компонентов.
- Доли ресурсов
- Доли ресурсов — относительный вес объекта среди конкурентов одного уровня планирования, определяющий его приоритет при дефиците ресурса.
- Изоляция хоста
- Изоляция хоста — состояние в VMware vSphere HA, когда хост не получает сетевые контрольные сигналы других хостов и не достигает адресов проверки изоляции, но может выполнять ВМ.
- Лимит ресурсов
- Лимит ресурсов — верхняя граница потребления процессора, памяти или другого ресурса виртуальной машиной либо группой, действующая даже при наличии свободной ёмкости.
- Режим обслуживания
- Режим обслуживания — состояние хоста виртуализации, в котором на нём не запускают новые ВМ, а работающие ВМ предварительно эвакуируют, выключают или переводят в допустимое состояние.
- Резервирование ресурсов
- Резервирование ресурсов — настройка минимальной доли CPU, памяти или иных ресурсов, которую гипе рвизор выделяет виртуальной машине или пулу при конкуренции.
- Снимок состояния
- Зафиксированное гипервизором состояние поддерживаемых виртуальных дисков и конфигурации ВМ на определённый момент, иногда также памяти, к которому можно выполнить откат.
- Admission Control
- Admission Control — механизм VMware vSphere HA, резервирующий ресурсы кластера для восстановления ВМ и запрещающий запуск, если заданная отказоустойчивость нарушается.
- Affinity Rule
- Affinity Rule — правило DRS в vSphere для совместного или раздельного размещения ВМ либо обязательной или предпочтительной привязки ВМ к группе хостов или исключения из неё.
- CPU Ready
- CPU Ready — метрика планировщика ESXi, показывающая время, когда готовый к выполнению vCPU ожидает доступа к логическому процессору хоста (pCPU); это не загрузка CPU гостевой ОС.
- Datastore
- Логический контейнер хранилища в VMware для размещения файлов виртуальных машин (диски, конфигурации, логи)
- Datastore Heartbeat
- Datastore Heartbeat — механизм VMware HA, при котором хост отмечает свою активность на общем датасторе, помогая отличить потерю связи по управляющей сети от отказа хоста.
- DRS
- Функция VMware vSphere для управления размещением ВМ в кластере и балансировки ресурсов хостов с помощью рекомендаций или автоматических миграций vMotion.
- EVC
- Режим VMware vSphere, задающий общий набор функций CPU для ВМ и обеспечивающий совместимость vMotion между хостами с процессорами разных поколений одного производителя.
- Guest OS
- Операционная система, установленная в виртуальной машине и работающая под управлением гипервизора; не следует путать с хостовой ОС гипервизора типа 2.
- Hardware Compatibility List
- Hardware Compatibility List — перечень проверенных сочетаний оборудования и ПО, определяющий конфигурации, поддерживаемые для заданной платформы или продукта.
- Host Isolation Response
- Host Isolation Response — политика vSphere HA, задающая, оставить ли ВМ включёнными или остановить их для перезапуска на других узлах при изоляции ESXi-хоста.
- Resource Pool
- Иерархический контейнер VMware vSphere для объединения ВМ и дочерних пулов и распределения между ними ресурсов CPU и памяти.
- Uplink
- Uplink — соединение или интерфейс, ведущий от устройства либо локального сегмента к вышестоящей сети; в виртуализации — подключение виртуального коммутатора к физической сети.
- vCenter Server
- Централизованная система управления инфраструктурой VMware для администрирования множества ESXi хостов из единого интерфейса
- vCPU
- vCPU — виртуальный логический процессор, предоставляемый виртуальной машине; гипервизор планирует его выполнение на процессорных ресурсах хоста.
- VM Monitoring
- VM Monitoring — функция VMware vSphere HA, которая по heartbeat VMware Tools и активности ввода-вывода выявляет зависание гостевой ОС и выполняет аварийный сброс (reset) ВМ.
- vMotion
- Технология VMware vSphere для переноса включённой виртуальной машины между хостами ESXi без выключения гостевой ОС; при переключении возможна краткая пауза.
- VMware ESXi
- VMware ESXi — гипервизор типа 1, устанавливаемый непосредственно на совместимый физический сервер для запуска и управления виртуальными машинами.
- VMware Tools
- Набор гостевых драйверов и служб VMware, улучшающий интеграцию виртуальной машины с гипервизором и средствами управления.
- vSphere
- Платформа виртуализации VMware, включающая гипервизор ESXi и средства управления vCenter для корпоративной инфраструктуры