Switch from Host to x86-64-v3

[moored99]

The following youtube video suggest that host mode has a performance bottle neck and is slower than if you use x86-64-v3 is this true ?

https://www.youtube.com/watch?v=CU5j_XeUg20

I need to point out I use quite few Windows VM's

 

[dcsapak]

aside from that video very obviously being ai generated, the underlying point is not wrong. in modern windows versions, using 'host' cpu mode activates VBS (virtualization based security) which can incur a heavy performance penalty. Alternatively to changing the cpu mode, it might be possible to deactivate VBS in the guest too...

edit: or (like in this thread described: https://forum.proxmox.com/threads/yawgpp-yet-another-windows-guest-performance-post.181030/ ) it should be possible to

If I recall correctly you should also be able to use host + disabled flag for nested virtualization to get a good performance and maximum features of your cpu

 

[ness1602]

If you need something like AfterEffects inside vm you can use max as cpu type.

 

[bitranox]

using 'host' cpu mode activates VBS (virtualization based security)

interesting ! and useful ! because that can be switched off in the windows 11 guest.


my trusted Ki says (still need to test it) :

In a Windows 11 VM, exposing more real CPU virtualization capabilities with -cpu host can allow Windows to enable VBS features that may stay off under a more limited virtual CPU model. Windows 11 22H2 and later can enable VBS and Credential Guard by default on eligible systems, and when Credential Guard is enabled, VBS is enabled too.


To disable it inside the Windows 11 guest, do these in order:

1. Turn off Memory integrity
   Open Windows Security → Device security → Core isolation details → switch Memory integrity to Off, then reboot. Microsoft documents Memory integrity under Core isolation in Windows Security.
2. Disable the VBS policy
   Run gpedit.msc and go to:
   Computer Configuration → Administrative Templates → System → Device Guard → Turn On Virtualization Based Security → set it to Disabled. Then reboot. Microsoft guidance and Microsoft support guidance both point to this policy path for disabling VBS/Credential Guard when they are policy-controlled.
3. If it still stays on, disable Credential Guard too
   Credential Guard is one of the things that uses VBS, and Microsoft states that when Credential Guard is enabled, VBS is automatically enabled. So if VBS keeps coming back, Credential Guard is often the reason.
4. Verify after reboot
   Run msinfo32 and check Virtualization-based security. If it says Not enabled, you are done. Microsoft support references msinfo32 as the place to confirm VBS state.

If the GUI and Group Policy do not stick, use the registry fallback in the guest:

• HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\DeviceGuard
• Set EnableVirtualizationBasedSecurity to 0
• Reboot

That registry value is commonly referenced in Microsoft guidance for disabling VBS when the UI is not enough.


If you want it fully off, also check Windows optional features and make sure guest-side hypervisor components are disabled, such as Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform, because these can keep the hypervisor active in some setups. Microsoft support guidance mentions these as additional things to disable when VBS or the hypervisor remains active.

Most likely explanation for your Proxmox/QEMU case:

• host exposes a richer CPU to the guest.
• Windows then decides the VM is eligible for VBS / Credential Guard.
• x86-64-v3 may expose a narrower feature set, so Windows does not auto-enable the same security stack.

 

[bitranox]

The idea is quite comprehensive, but have you considered this scenario? Features like Hyper-V, Virtual Machine Platform, and Windows Hypervisor Platform all use the same Windows hypervisor layer, so if one of these components is still enabled, the system can still run the hypervisor in the background. Therefore, checking and disabling all Windows Optional Features related to virtualization is a logical step when you want to completely disable the hypervisor or handle this situation

I dont understand what You want to tell me.
I need Hyper-V on that Machine, but want to use the fastest CPU type possible. Maybe its possible to switch off the VBS (virtualization based security) and still use Hyper-V Guests.

VBS (virtualization based security) <> Hyper V Capability (Hyper-V is working just fine when selecting x86-64-v2 / x86-64-v3)