I think my previous message didn’t explain the actual problem clearly enough, so it might have caused some confusion. The bug you mentioned doesn’t seem related to what we’re seeing. In our case, the issue happens specifically when Nova’s cpu_models is set to IceLake variants (Icelake-Server-noTSX or Icelake-Server). With those models, Windows 11 VMs go into a boot loop after enabling nested virtualization features like Hyper-V or WSL. Windows 10 works fine, and Windows 11 also works fine if we use older CPU models like Broadwell or Cascadelake. The part about our compute nodes using Emerald Rapids CPUs was just for full system context — it’s not the root cause. Update: I suspect this might be a QEMU-side issue, so I’ve also opened a report on the QEMU GitLab. If anyone wants to follow it: https://gitlab.com/qemu-project/qemu/-/issues/3215 ________________________________ From: Hoai-Thu Vuong <thuvh87@gmail.com> Sent: Friday, November 21, 2025 11:23 AM To: Hai Pham Thanh <haipt43@fpt.com> Cc: openstack-discuss@lists.openstack.org <openstack-discuss@lists.openstack.org> Subject: Re: [nova][libvirt][qemu] Windows 11 Nested Virtualization Boot Loop on OpenStack (Emerald Rapids Hosts) does this bug<https://bugs.launchpad.net/ubuntu/+source/libvirt/+bug/2106812> related your report? On Thu, Nov 20, 2025 at 9:23 PM Hai Pham Thanh <haipt43@fpt.com<mailto:haipt43@fpt.com>> wrote: Hi community, We would like to report an issue we are encountering with nested virtualization on Windows 11 instances running on OpenStack. On our OpenStack platform, a Windows 11 VM becomes unable to boot after enabling Virtual Machine Platform/Hyper-V inside the VM and performing a hard reboot (VM does not show a BSOD but fails to boot into the OS and gets stuck in a boot loop in Tianocore logo). This issue does not occur on Windows 10 under the same conditions. System: * Compute node CPU: Intel Xeon Gold 6538Y+ (Emerald Rapids) with nested virtualization is enabled. * OpenStack 2024.2 * libvirt 8.0.0 * QEMU API 8.0.0 * QEMU hypervisor 6.2.0 Initially, our Nova CPU configuration was: * cpu_mode=host-model * cpu_model_extra_flags=+vmx,-hypervisor,-xsaves According to virsh dumpxml, host-model maps to Icelake-Server. We tested several cpu_mode=custom configurations and observed the following: * cpu_models=Icelake-Server-noTSX → error (boot loop) * cpu_models=Icelake-Server → error (boot loop) * cpu_models=Broadwell-noTSX-IBRS → works * cpu_models=Cascadelake-Server-noTSX → works The working models correspond to the Preferred CPU models recommended by QEMU: https://qemu-project.gitlab.io/qemu/system/qemu-cpu-models.html#preferred-cp... We would like to ask: 1. Has anyone encountered this issue with Windows 11 + nested virtualization on Icelake/Emerald Rapids hosts? 2. Are there known root causes explaining why newer CPU models fail while preferred (older) models work? 3. Is there a recommended fix other than switching to a preferred older CPU model? Best regards, Hai Pham -- Thu.