CPU кластера: совместимость и резерв для VM

Виртуальная машина объединяет гостевую ОС, приложения и виртуальные ресурсы. Приёмку планируют для этой среды целиком, а не для одного названия CPU.

Запишите CPU, микрокод, RAM, гипервизор, устройства и сеть каждого сервера. Укажите процессорные требования VM. Помимо имени модели QEMU зафиксируйте её фактическую версию и тип машины.

Сравнение физического CPU не заменяет проверку того, какой CPU предоставит гипервизор. Для описанного вызова BaselineHypervisorCPU берут host-model из описания возможностей виртуальной платформы. Флаг IGNORE_HOST здесь не применяют: при нескольких CPU он исключает возможности гипервизора из расчёта.

Для host-passthrough libvirt требует сопоставить оборудование, QEMU, микрокод и настройки. Параметр migratable=on, описанный с 6.5.0, не снимает этих условий. Не подменяйте ими стендовую проверку.

У host-model модель сохраняется для мигрирующего работающего экземпляра, но может измениться после полного выключения и нового запуска. Проверяйте эти две операции отдельно; границы версий приведены в утверждении.

Помимо CPU, при миграции передаётся состояние устройств. Зафиксируйте тип машины и версии ПО для прямого и обратного переноса: проверка одного направления не доказывает другое.

Учебные условия: VM на A; её CPU допустим на A и B, но не на C. Данные, сеть и RAM доступны. После отказа B узлы A и C исправны, однако перенести эту VM с A некуда. В расчёте резервирования нет ни одного другого допустимого назначения.

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