vSphere 8.0 Update 1c resolves Windows VBS performance & Hyper-V Generation 2 Nested VM running on AMD CPU

🆕 vSphere 8.0 Update 1c is now available! Includes support for TKr 1.25.7 🥳

📔RN
VC https://t.co/4y2s91PcKY
ESXi https://t.co/RYI0gz7vtf
TKr https://t.co/KiarKzkQs0

💿 DL
VC https://t.co/w0cyBErTiC
ESXi https://t.co/MuCPqieXY3

— William Lam (@lamw.bsky.social | @*protected email*) (@lamw) July 28, 2023

vSphere 8.0 Update 1c was just released and one of the resolved issues mentioned in the ESXi release notes is the following:

Nested virtual machines on AMD CPUs with operational systems such as Windows with virtualization-based security (VBS) might experience performance degradation, timeouts, or unresponsiveness due to an issue with the virtualization of AMD's Rapid Virtualization Indexing (RVI), also known as Nested Page Tables (NPT).

UPDATE (10/11/23) - This is also resolved in the ESXi 7.0 Update 3o release

There are two scenarios in which this fix resolves:

1. Running Windows Server VM with a Hyper-V enabled Generation 2 VM (Nested Virtualization) on AMD CPU
2. Running Windows Server VM with VBS Enabled (Non-Nested VM) on AMD CPU

The original issue that was reported in the VMTN Community, which I had filed an internal bug report with Engineering, is related to the first scenario. The reported issue was that when a user would power on a Hyper-V Generation 2 VM (Nested) running in a Windows Server VM hosted on an AMD CPU, the inner-VM would not boot and simply show a blank screen.

If the user switched to a Generation 1 Hyper-V VM, then the VM would boot up properly. Furthermore, this issue was not observed when using an Intel CPU and both Generation 1 and 2 Hyper-V VMs were functional.

In the second scenario, we also had reports from some customers that they had noticed a performance degradation when running a Windows Server VM with just Microsoft Virtualization Based Security (VBS) enabled and they were not running any Hyper-V VM inside.

Both scenario 1 and 2 are related since the way VBS is implemented by Microsoft, it is actually using a Hyper-V VM and this is also why you may have noticed Virtual Hardware Virtualization (VHV) setting automatically enabled when you configure a Windows VM with the VBS setting.

For customers that are on vSphere 8.x and affected by this issue, you can resolve this by installing the latest ESXi 8.0 Update 1c patch. For customers on vSphere 7.x, a similiar fix will also be available in a future ESXi patch update, so stay tuned.