6 Step KVM Nested Virtualization Setup for Sysadmins, Avoid TCG Emulation

Yes, KVM supports nested virtualization on both Intel and AMD hosts. Run cat /sys/module/kvm_intel/parameters/nested (or kvm_amd on AMD) to check the current state, and confirm vmx or svm shows up in cat /proc/cpuinfo. If the parameter returns N, add options kvm_intel nested=1 (or kvm_amd nested=1) to a modprobe config file and reload the module or reboot.

TL;DR:

• Hardware support requires CPU flags vmx on Intel or svm on AMD, along with enabled nested parameter set to “Y” or “1”; without these, enabling nested virtualization won’t work.
• Enabling nested requires editing modprobe configuration, reloading modules, and confirming the setting persisted, with a full reboot if modules fail to unload cleanly.
• Exposing CPU features to the guest involves choosing the appropriate CPU mode, either host-model or host-passthrough, to maximize nested performance and compatibility.
• Running nested VMs outside bare-metal environments can face limitations if the hypervisor or cloud provider disables hardware virtualization extensions for guests.
• Nested virtualization incurs performance overhead, and issues like fallback to emulation or module conflicts can cause poor VM performance, requiring careful configuration and validation.

Table of Contents

• What Nested Virtualization Actually Means in KVM
• Checking Your CPU and Kernel Before You Enable Anything
• Enabling Nested Virtualization on the L0 Host
• Exposing Host CPU Features to Your L1 Guest
• Verifying the Setup Actually Works
• What Nested KVM Costs You in Performance
• Troubleshooting the Errors You’ll Actually Hit
• Why Hosted KVM Makes More Sense Than a Home Lab for This
• Get a Host That Actually Exposes Nested Virtualization
• Sources
• FAQ

What Nested Virtualization Actually Means in KVM

Nested virtualization stacks hypervisors three levels deep. L0 is the physical host running KVM directly on bare metal. L1 is a virtual machine that itself runs a hypervisor, often KVM again, sometimes VMware or Hyper-V for compatibility testing. L2 is the guest running inside that L1 hypervisor. When people say “nested KVM,” they mean L1 is using hardware-accelerated virtualization instructions passed through from L0, not software emulation.

That distinction trips up a lot of admins. If L1 boots a VM using QEMU’s TCG (Tiny Code Generator) emulation instead of real VMX/SVM instructions, the VM runs, just brutally slowly, and nobody notices until a workload chokes. The Linux kernel’s own nested guest documentation is explicit that hardware-accelerated nesting requires the CPU flags and module parameters to actually be active, not just present.

Common uses for this setup:

• CI pipelines that spin up disposable hypervisor environments for integration tests
• Multi-OS lab environments simulating a data center on one physical box
• Testing migration behavior between hypervisor versions before a production rollout
• Training environments where students each get a virtual “host” to break safely

Nested KVM is not something you want under latency-sensitive production traffic. Treat it as a development and testing tool, not a production architecture.

Checking Your CPU and Kernel Before You Enable Anything

Before touching any config file, confirm the hardware and kernel actually support this. Run cat /proc/cpuinfo | grep -E 'vmx|svm'. Intel CPUs need vmx plus ept (Extended Page Tables) for reasonable performance; AMD needs svm plus npt (Nested Page Tables). No flag, no nesting, full stop, regardless of what any config file says.

The kernel has shipped with nesting enabled by default since version 4.20, according to kernel documentation, but distributions frequently override that default for stability reasons. Never assume; always check /sys/module/kvm_intel/parameters/nested or /sys/module/kvm_amd/parameters/nested directly on your system.

Architecture matters too:

• On s390x architecture, nested virtualization and huge-page backing (hpage) cannot be enabled simultaneously at the kernel module level
• POWER9 systems have their own firmware-level requirements that differ from x86 entirely
• Red Hat Enterprise Linux still classifies nested virtualization as a Technology Preview, meaning it’s supported for testing but not backed by full production SLAs

Pro Tip: Stop any running VMs before you reload the kvm_intel or kvm_amd module. The kernel will refuse to unload a module that’s actively in use, and you’ll end up rebooting anyway.

On s390x specifically, trying to enable both hpage and nested support at once produces a hard failure. Attempting modprobe kvm hpage=1 nested=1 throws “could not insert kvm: Invalid argument,” and kernel mailing list discussion confirms this is a known architectural conflict, not a misconfiguration on your part.

Enabling Nested Virtualization on the L0 Host

Start by checking where you stand. Run cat /sys/module/kvm_intel/parameters/nested on Intel hardware or cat /sys/module/kvm_amd/parameters/nested on AMD. A “Y” or “1” means you’re already good to go; an “N” or “0” means you need to flip it.

Here’s the sequence to enable it persistently:

1. Create or edit /etc/modprobe.d/kvm.conf
2. Add options kvm_intel nested=1 for Intel systems, or options kvm_amd nested=1 for AMD systems
3. Stop any running VMs on the host
4. Unload the module with modprobe -r kvm_intel (or kvm_amd)
5. Reload it with modprobe kvm_intel (or kvm_amd)
6. Verify with cat /sys/module/kvm_intel/parameters/nested again

If unloading fails because the module is busy, reboot instead. Ubuntu Server’s documentation walks through this exact sequence and notes that nested is enabled by default on Ubuntu x86 builds, though that default can still be overridden by hardware BIOS settings or hypervisor-level restrictions on cloud instances.

Pro Tip: If you’re running this inside a cloud VM rather than bare metal, check whether your provider exposes VMX/SVM to guests at all. Many budget VPS platforms disable nested support at the hypervisor layer regardless of what your kernel reports, which is why dedicated high-performance hosts matter for this kind of work.

Watch for a specific pitfall: some distributions ship a modprobe blacklist or override file elsewhere in /etc/modprobe.d/ that silently cancels your new setting. If your change doesn’t stick after a reboot, grep the whole directory for nested before assuming the kernel itself is broken.

Exposing Host CPU Features to Your L1 Guest

Enabling nesting at the host level is only half the job. Your L1 guest also needs visibility into the CPU’s virtualization instructions, which means configuring the guest’s virtual CPU model correctly.

In libvirt XML, you have two realistic choices:

• <cpu mode='host-model' check='partial'/> copies most host CPU features while keeping some abstraction, which plays nicer with live migration between similar but not identical hosts
• <cpu mode='host-passthrough'/> exposes the full physical CPU to the guest, including every virtualization extension, at the cost of migration compatibility, since the destination host must match almost exactly

For raw QEMU command-line use, -cpu host is the direct equivalent of host-passthrough. If you’re stuck with a generic CPU model for compatibility reasons, you can still add the flag manually: -cpu qemu64,+vmx on Intel systems exposes VMX without switching the whole CPU model. The kernel’s nested VMX documentation confirms no additional user-space patches are needed here, it’s purely a matter of CPU flag exposure through QEMU or libvirt.

In virt-manager’s GUI, the CPU configuration tab has a “Copy host CPU configuration” checkbox that does the same thing as host-passthrough without touching XML directly. For cases needing nested Hyper-V acceleration on Windows L1 guests, you’ll also want <feature name='vmx' policy='require'/> or the cap-nested-hv flag noted in libvirt’s CPU model documentation.

The tradeoff is straightforward: host-passthrough gets you maximum feature exposure and the best nested performance, but locks you to hardware-identical migration targets. Host-model gives up some nested capability for flexibility. Pick based on whether this L1 guest will ever need to move.

Verifying the Setup Actually Works

Getting a clean nested configuration means checking from inside L1, not just trusting L0’s settings. Run through this sequence:

1. Inside the L1 guest, run cat /proc/cpuinfo | grep -E 'vmx|svm' to confirm the flag made it through
2. Run lsmod | grep kvm to check whether kvm_intel or kvm_amd loaded inside L1 itself
3. Check cat /sys/module/kvm_intel/parameters/nested inside L1 (yes, again, one level up)
4. Boot a minimal L2 test VM and confirm it starts without falling back to TCG emulation
5. Run kvm-ok (on Debian/Ubuntu-based systems) inside L1 to get a plain-language confirmation

If step 4 produces a VM that boots but performs like it’s wading through mud, you’re likely on emulation rather than hardware acceleration. Check dmesg for kernel messages referencing KVM. Genuine bugs sometimes surface as kernel BUG or OOPS messages specifically tied to nested guest state during migration attempts, and those are worth capturing in full before filing anything upstream. Save the exact dmesg output and your libvirt XML together, since bug reports without both are nearly impossible to reproduce.

What Nested KVM Costs You in Performance

Nested virtualization is not free, and no distribution documentation pretends otherwise. Every instruction that would normally trap directly to hardware now traps through an extra layer, and Red Hat’s own guidance recommends nested KVM for development and testing rather than high-throughput production use cases specifically because of this overhead.

A few concrete limitations to plan around:

• Some VMX features are not fully supported upstream and may not be properly exposed to nested guests
• Live migration of L1 guests while L2 guests are running can cause undefined behavior on AMD hosts, per kernel documentation
• On s390x, the hpage conflict mentioned earlier rules out combining nesting with huge-page memory backing entirely
• Migrating L2 guests tends to be more reliable than migrating L1 guests with nested guests, especially with recent kernel and QEMU versions on Intel hardware

Pro Tip: Size L1 generously. A starved L1 with 2 vCPUs trying to run three nested L2 guests will produce scheduling contention that looks exactly like a broken nested config but isn’t. Give L1 real headroom before you start debugging.

Troubleshooting the Errors You’ll Actually Hit

Most nested KVM problems fall into a small handful of buckets. Here’s how to work through them fast:

1. Nested parameter shows 0 after you set it: the module didn’t reload cleanly, or a separate modprobe file overrode your setting. Grep /etc/modprobe.d/ for conflicting entries, then reload the module with VMs stopped.
2. L1 guest can’t see VMX/SVM at all: your libvirt CPU mode is likely still set to a default model. Switch to host-model or host-passthrough and restart the guest, not just the running VM.
3. modprobe fails outright with “Invalid argument”: on s390x, this almost always means hpage and nested are both requested simultaneously. Disable hpage backing before reloading.
4. L2 boots but crawls: check whether TCG emulation kicked in instead of hardware acceleration. Run kvm-ok inside L1 to confirm.

When collecting logs for a bug report, grab dmesg output from both L0 and L1, your libvirt domain XML, and the exact kernel version on each layer. Roll back changes in reverse order (undo CPU mode changes in the guest XML, then module parameter changes on the host) and re-test one variable at a time. Never push a nested config change directly into a production-adjacent environment without validating it on a throwaway VM first, since a failed module reload can force an unplanned reboot of the entire host.

Why Hosted KVM Makes More Sense Than a Home Lab for This

Building a bare-metal nested lab at home means buying hardware with the right CPU flags, babysitting BIOS settings, and hoping your consumer motherboard doesn’t quietly disable VT-x nested mode in some firmware update. That’s a lot of overhead for testing a CI pipeline or validating a migration path.

Running nested KVM experiments on a properly provisioned VPS can avoid much of that friction if the host exposes VMX or SVM to the guest, which not every budget provider does. AceRDP’s KVM VPS plans run on AMD Ryzen-based infrastructure with NVMe storage and low network latency, suitable for nested workloads since L1 is already carrying overhead before L2 even boots. Instant provisioning also means you can spin up a disposable L1 test host, break it deliberately, and rebuild it in minutes rather than re-imaging physical hardware.

For admins who need a repeatable lab environment without owning the metal, that combination of raw CPU performance and fast provisioning matters more than it sounds like on paper.

— AceRDP

Get a Host That Actually Exposes Nested Virtualization

AceRDP offers hosts that expose VMX or SVM down to the guest, enabling nested KVM to function properly the way the documentation says it should instead of silently falling back to emulation. Built on AMD Ryzen CPUs with NVMe storage, the infrastructure keeps L1 overhead from turning into a bottleneck when you’re stacking a second hypervisor layer on top.

Setting up a nested lab on AceRDP takes a few practical steps: pick a plan with enough vCPU and RAM headroom for both L1 and its L2 guests, confirm module options with nested=1 once your server provisions, then set your libvirt CPU mode to host-passthrough for full feature exposure. Instant provisioning means you can rebuild the whole stack from scratch in minutes if a test goes sideways.

Check current AceRDP VPS plans and pick a configuration sized for the number of nested guests you plan to run.

Sources

• Running nested guests with KVM — The Linux Kernel documentation
• Chapter 19. Creating nested virtual machines — Red Hat Documentation
• Enable nested virtualization — Ubuntu Server documentation

FAQ

What is KVM virtualization?

KVM (Kernel-based Virtual Machine) is a Linux kernel module that turns the kernel into a type-1 hypervisor, letting the host run virtual machines using hardware-assisted virtualization extensions like Intel VT-x or AMD-V.

Is nested virtualization possible with KVM?

Yes. KVM has supported nested virtualization on both Intel and AMD hardware for years, and it’s been enabled by default in the upstream kernel since version 4.20, though individual distributions may still ship it disabled.

Which hypervisor is best for nested virtualization?

KVM is generally the most flexible option for nested setups because it combines native Linux kernel integration with detailed upstream documentation covering both Intel VMX and AMD SVM nesting paths, plus strong support in libvirt and QEMU tooling.

Is KVM better than Hyper-V?

They target different environments. KVM integrates natively into Linux and gives administrators direct control over kernel module parameters and CPU exposure, while Hyper-V is built for Windows Server environments; for Linux-based nested lab work, KVM’s tooling and documentation depth make it the more transparent choice.

How do I know if nested virtualization is actually working, not just emulated?

Check /proc/cpuinfo inside the L1 guest for vmx or svm flags and confirm /sys/module/kvm_intel/parameters/nested (or kvm_amd) reads Y or 1; if an L2 VM boots but performs poorly despite this, it may still have fallen back to QEMU’s TCG emulation.