libvirt + WinServer 2025 = black screen при загрузке

Наткнулся на добротные грабли. Возможно, эта заметка позволит кому-то сэкономить время, возможно много ;)

Развёрнуто небольшое тестовое окружение. 

• Есть физический ПК под управлением debian 12. 
• Установлены libvirt (qemu/kvm) + virt-manager. 
• Создано несколько виртуальных машин (ВМ) под управлением windows server 2025 (dc, rdc). 
• В ВМ установлены необходимые пакеты для работы с libvirt.

 Далее. Добавляется новая машина windows server 2025. 

Машина присоединяется в домен, для работы с хостовыми шарами на неё накатываются WinFsp и добавляется файловая система firtiofs, пример: Shared-file-system.

Всё работает ок.

После ребута получаем чёрный экран при попытке загрузки windows. Система грузится, но в момент переключения видеорежима получаем чёрный экран.

До перезагрузки всё работает ок. 

• После перезагрузки - чёрный экран и потребление на 100% одного ядра. Система не загружается. 
• В режим восстановления зайти можно. 
• При этом последняя удачная конфигурация не загружается 
• Ручная остановка службы virtio-fs service к успеху не привела 
• Попытка переименовать папки WinFsp и Virtio-Win (чтобы не загружались расположенные там драйвера) тоже оказалась безуспешной.

 Не буду подробно описывать все свои злоключения. 

• ОС на ВМ была переустановлена несколько раз. При этом сама ВМ, конечно создавалась заново.
• Вдумчивое чтение журналов системы не позволило приблизиться к решению ни на йоту.
  
• На каком-то этапе перестал устанавливать WinFsp - не помогло. Проблема оказалась не в WinFsp.
• Были проведены эксперименты с использованием разных типов дисков.
• Много проверок и попыток поиграть с видеокартами.
• Чтобы локализовать ошибку собиралась минимальная живая конфигурация - всё потенциально "лишнее" и не обязательное оборудование удалялось.
• На каком-то этапе играл с процессором системы. Моментально получил полностью нерабочую систему.
  
• Что интересно, в режиме восстановления всё работало ок.
• Разные режимы аварийной загрузки, попытки сбора логов - всё впустую.  
  

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

Времени было потрачено - страшно сказать вслух.

 

Очередные два часа гуглежа помогли вытащить золотую рыбку.

https://hartiga.de/windows-server/windows-server-2025-on-ugreen-nas/ 

Replace that block with the following “Stable” configuration:XML<cpu mode='custom' match='exact' check='none'> <model fallback='allow'>Skylake-Client-IBRS</model> <topology sockets='1' dies='1' cores='6' threads='1'/> </cpu> (Note: Ensure cores='6' matches your actual assigned core count!)

Skylake-Client-IBRS is a “safe harbor” CPU model in the virtualization world. It includes modern instruction sets required by Windows Server 2025 but abstracts away the specific quirks of the physical NAS processor. It also includes IBRS (Indirect Branch Restricted Speculation), which is critical for security mitigations (Spectre/Meltdown) that Windows expects to see present.

Бинго!

• Почему и откуда прилетели такие грабли - совершенно непонятно. Но выглядят они так.
• Почему баг прилетал после нескольких успешных загрузок - непонятно.
• Почему при этом работают другие WinServer (dc, rdc) - тоже непонятно.

Хостовый CPU: Intel(R) Core(TM) i7-14700KF

В качестве очевидного после этой ошибки вывода: вслепую использовать host-passthrough не очень хорошая идея.

Внятных  рекомендаций на тему у самого разработчика для себя найти не смог https://www.qemu.org/docs/master/system/i386/cpu.html Единственное полезное, что смог извлечь - конфигурацию Skylake-Server-IBRS с ней сервер тоже вполне себе заработал.

Удачи в правильном выборе железа для ВМ ;)

PS В боевом окружении, конечно лучше десять раз подумать о выборе типа процессора, т.к. например поломанная живая миграция - это больно.