Nested Virtualization on a Windows VPS: Running Hyper-V Inside a Guest

Nested virtualization is the requirement that stops most Hyper-V lab plans on a VPS: the guest Windows Server sees a CPU without the VMX or SVM flag, and Install-WindowsFeature Hyper-V reports that virtualization support is not present. Whether it works depends entirely on the host exposing the flag to your VM, which is a provider-side setting you usually cannot see from inside.

When it does work, the performance is not what the product page implies. A guest hypervisor adds one more translation layer to every memory access and every exit, and on a VPS the same physical cores are already shared. Before you commit a weekend to a nested lab, measure the tax honestly.

Start by confirming what the provider actually gives you. On a Windows VPS with an exposed virtualization flag, systeminfo will report “A hypervisor has been detected” and task manager shows “Virtual machine: Yes”. The critical line is inside the VMX/SVM capability report, not the presence of Hyper-V in the host.

The host-side enablement requirement

On Hyper-V hosts, the setting is a per-VM processor flag: Set-VMProcessor -VMName lab01 -ExposeVirtualizationExtensions $true. On VMware platforms it is a pair of VMX entries, vhv.enable = TRUE and hardware-assisted virtualization exposure, plus an EVC mode that is not disabled. On KVM it is -cpu host with nested enabled on the host module. None of these can be changed from inside the guest.

Ask the provider directly whether nested virtualization is enabled, and ask for the specific answer in writing: which hypervisor, which CPU generation, and whether the flag is exposed per VM. A generic “yes, we support Hyper-V” often means the host runs Hyper-V, not that your guest can. If the answer is unclear, boot a Linux live image and read /proc/cpuinfo for vmx or svm before building anything.

# In the guest, before installing Hyper-V
systeminfo | Select-String "Hyper-V","Virtualization"
Get-CimInstance Win32_Processor | Select Name,VirtualizationFirmwareEnabled,
  SecondLevelAddressTranslationExtensions
coreinfo64.exe -v   # shows VMX/SVM present and usable

# Host-side equivalent (if you control it)
Set-VMProcessor -VMName lab01 -ExposeVirtualizationExtensions $true

What the flag actually exposes

Exposing VMX or SVM lets the guest hypervisor run hardware-accelerated virtual machines instead of falling back to emulation. Without it, Hyper-V installs but every nested guest either fails to start or runs on a software path that is roughly 20–40 times slower. With it, the nested guest gets its own VMCS and real hardware exits, routed through the outer hypervisor.

Second-level address translation matters as much as the flag. Nested EPT/NPT is what keeps memory translation from being emulated, and on hosts without nested SLAT performance collapses under any memory-heavy workload. Check for it explicitly; a CPU that reports VMX but no SLAT is not a usable nested host.

The performance tax you should measure

Expect three costs. First, exit latency: each nested VM exit traverses two hypervisors, adding 2–10 microseconds per exit, which shows up as higher CPU cost on syscall-heavy and interrupt-heavy workloads. Second, memory: nested guests need their own RAM plus the outer VM’s overhead, and the outer layer cannot deduplicate page cache between levels.

Third is scheduling. The outer hypervisor schedules the inner hypervisor’s vCPUs as threads, so a nested guest with four vCPUs needs four runnable host threads simultaneously. On a 4 vCPU VPS, nested guests should be configured with 1–2 vCPUs; more just increases the chance of vCPU wait.

Test	Bare VPS	One level nested	Tax
CPU integer (single)	100%	88–94%	6–12%
Disk 4K random IOPS	100%	70–85%	15–30%
Network throughput	100%	60–80%	20–40%
Boot to desktop	baseline	+40–80%	—
Context switch cost	baseline	+2–10 µs	—

Run the same test twice: once on the outer VPS directly, once on a nested guest with equal resources, using a benchmark that produces a single number you can compare — CPU-Z single-thread, diskspd with a fixed 4K pattern, and iperf3 between two nested guests on the same virtual switch. Keep the outer load identical between runs or the comparison is noise.

Sizing the lab for the tax

If the tax is 20% on disk and 30% on network, a lab that needs the equivalent of a 2 vCPU, 8 GB, 100 GB VM needs roughly a 4 vCPU, 16 GB, 200 GB outer VPS. Round up rather than down, because nested guests cannot borrow capacity the outer host has not reserved. Leave 25% of outer RAM unallocated for the outer hypervisor itself.

Storage is the usual bottleneck. Nested VHDXs add write amplification: a write inside the inner guest passes through the inner virtual disk, the outer virtual disk, and finally the provider’s storage layer. On a thin-provisioned VPS disk, a fio test writing 50 GB of random data can consume 150 GB of physical space. Monitor the outer disk usage weekly.

Verifying the nested guest works

After Hyper-V installs and reboots, create one nested VM and check that it starts in the running state rather than crashing at 0% — a guest that immediately stops usually means the virtualization extension was not exposed. Confirm Get-VMProcessor on the inner VM shows the expected count, and look at the outer VM’s CPU usage while the nested guest idles: flat near zero is healthy, sustained 10% at idle means exit overhead.

Check the inner guest’s own systeminfo — it should report a hypervisor present and no device problems. Then run a snapshot, restore it, and start the VM again. Snapshot chains inside a nested guest is the workflow people actually want, and it is the first thing that breaks when the outer platform restricts disk operations.

When nested is the wrong choice

• You need more than two nested guests — use separate VPS instances instead.
• The workload is latency-sensitive (databases, trading, real-time control).
• You need nested guests with more than 2 vCPUs each on a small VPS.
• The provider cannot confirm the virtualization flag in writing.
• You only need containers — use Hyper-V containers or WSL2 instead of full VMs.

Nested Hyper-V is genuinely useful for teaching, for testing cluster scenarios, and for building a throwaway domain you can snapshot and destroy. It is a poor fit for anything that has to serve production traffic, because the outer layer owns the scheduling and you cannot tune it. Measure first, then decide whether the convenience is worth the 20–30% throughput you will not get back.

Document the measured numbers next to the lab build so the next person knows what the environment actually delivers. A nested lab on a VPS instance built for virtualization testing is cheap enough to keep around, and expensive only when it is sized by hope rather than by the benchmark table above.