Для ЛЛ: читайте логи, они очень полезны
Когда-то давно, то есть года два назад, еще до окончательной победы Linux, существовала такая фирма – VMware. Больше не существует. Одним из простых, дешевых и надежных продуктов VMware была операционная система ESXi, которая почти ничего не умела, особенно после того, как из нее удалили остаток Linux, и возможность загружать в ядро ОС – какие попало драйвера. Но это уже другая история. А так, ESXi – это гипервизор, чуть лучше чем MS Hyper-V, но резко отстающий от KVM, в том числе по причине чудовищно переусложненного в работе планировщика использования ядра, по сравнению с CFS, и тем более, EEVDF. Кому это вообще надо, прибивать гвоздями VM к 1,2, и 20 ядрам?
Одной из функций этой ОС было обеспечение высокой доступности виртуальных машин. Функция работала крайне просто – в группе физических хостов выбирался мастер, который следил за доступностью остальных хостов. Если какой-то хост переставал отвечать на запросы, считалось что он вышел из строя, и дальше отрабатывал механизм обработки отказа. Сначала это был Automated Availability Manager, затем Fault Domain Manager (FDM) .
Почитать про эту древность 15 летней давности можно тута , а посмотреть как это работает теперь – здеся, в лабораторной работе vSphere High Availability , или почитать в книжке vSphere Availability VMware vSphere 7.0 Update 3
vSphere Clustering Service (vCLS)
В VMware vSphere 7 U1 был презентован дополнительный механизм наблюдения за доступностью - vSphere Clustering Service (vCLS), представляющий из себя три очень маленькие служебные виртуальные машины на хост, обслуживающие vCLS Control Plane. https://vm-guru.com/news/vmware-vsphere-clustering-services
Механизм работал плохо, и работает очень плохо. Настолько плохо, что кнопку «отключить эту поделку» перенесли из служебных настроек кластера в главное меню, и написали огромную статью - How to Disable vCLS on a Cluster via Retreat Mode
При этом, разбираться «почему так» и писать какой-то deep dive никто не стал.
Между тем, немногочисленные оставшиеся программисты все же написали (наконец-то!) нормальное логирование, и теперь, иногда, можно в hostd.log увидеть строку infra/vCLS .. Power On message: Feature 'cpuid.mwait' was 0, but must be 0x1.
Раньше, давно, было сложнее – просто VM писала «нишмагла» - vCLS VMs fail to power on with an error message "Insufficient resources" in vSphere 7.0 Update 1 or newer или ничего не писала или еще 100 вариантов из статьи vSphere Cluster Services (vCLS) Known Issues/Corner Cases, или обращаться вместо Маркса в eam.log или применять черную магию вне Дурмстранга:
/etc/init.d/infravisor status
inf-cli get pods -n vcls
configstorecli config current set -c esx -g infravisor_pods -k vcls -p /pod_settings/enabled -v true
monitor/mwait instructions
mwait – это даже не черная магия, это нечто, что сделано чтобы сэкономить .. чего-то
Проблема в том, что у разных производителей материнских плат – разное понимание, нужно ли это вообще, и в какой раздел конфигурации это положить. Или же, вообще поставить режим работы «Auto», но что это значит в конкретных задачах – понять можно далеко не всегда. Но, как выясняется, спустя 4 года проблем - надо ставить 1. Что значит включено.
The below three situations are possible when Monitor/MWAIT is disabled:
Cluster-wide EVC issues prevent enabling EVC
VM-based EVC settings (introduced with vSphere 6.7) prevent turning as well as moving VMs
vCLS (vSphere Cluster Services) introduced with vCenter 7.0 U1 prevents to start vCLS VMs
Переходить на KVM конечно, там такого нет и не будет.