How nestedvirt uses KVM nested_run counters to help OpenStack and KVM operators decide whether disabling nested virtualization is operationally safe.
In our previous post on CVE-2026-53359, we described the issue as a compute isolation concern for x86 KVM hosts that expose nested virtualization to untrusted guests. The immediate operational question for many teams is narrower but just as important: can nested virtualization be disabled without breaking running workloads?
That question is difficult to answer from configuration alone. A host may expose VMX or SVM to guests, but that does not prove that a workload is actively using nested virtualization. A tenant may also require nested virtualization even if the platform team has no explicit record of that dependency. The right response is to collect host-local evidence before making a broad policy change.
To make that review easier, VEXXHOST has released nestedvirt, a small Go tool and library for detecting KVM guests that have used nested virtualization on a Linux host.
Why Usage Detection Matters
CVE-2026-53359 is a Linux KVM/x86 vulnerability, not an OpenStack control-plane vulnerability. The risk appears where an affected KVM host exposes nested virtualization to a guest that can exercise the vulnerable path.
For OpenStack, this usually means Nova-managed compute hosts running QEMU/KVM. But the same operational question exists anywhere KVM is used: private cloud platforms, standalone libvirt hosts, virtualization clusters, CI hosts, lab environments, and managed infrastructure that allows a guest to run another hypervisor.
Disabling nested virtualization can be a reasonable interim risk-reduction measure while patched kernels are validated and rolled out. It can also be disruptive. Workloads that run KVM, QEMU, libvirt, KubeVirt, Android emulators, virtualization test suites, or VM-based CI inside a guest may stop working, fail in less obvious ways, or fall back to much slower software emulation.
That is why operators need evidence. The useful question is not only "is nested virtualization enabled?" It is "which currently running VMs have actually entered nested virtualization?"
How nestedvirt Works
KVM exposes per-VM debug counters under debugfs. One of those counters is nested_run, which increments when a KVM VM enters nested guest execution. A non-zero value is strong evidence that the VM has used nested virtualization during its current lifetime.
nestedvirt reads those KVM nested_run counters from /sys/kernel/debug, correlates non-zero counters with Linux process metadata from /proc, and identifies the userspace process attached to the VM. When the process looks like QEMU, the scanner extracts common QEMU and libvirt identity fields such as the guest name and UUID. It also discovers likely QMP or monitor sockets by joining the process file descriptor table with /proc/net/unix.
On libvirt-based systems, the tool connects to qemu:///system by default using pure-Go libvirt RPC support. It does not require linking against libvirt.so. For OpenStack environments, it can enrich findings with Nova metadata when that metadata is present in the libvirt domain XML. That makes it easier to map a KVM finding back to an OpenStack server, project, or flavor.
The tool is intentionally host-local. It does not need access to the OpenStack API, a cloud database, or tenant credentials. It works from the compute host evidence that KVM and Linux already expose.
Running a Scan
On a Linux KVM host, the fastest way to run the latest release is:
curl -fsSL https://raw.githubusercontent.com/vexxhost/nestedvirt/main/scripts/run-latest.sh | bash
The script downloads the latest release from GitHub, verifies the checksum, extracts the binary, and runs nestedvirt scan. If the scan is not run as root, the script will use sudo by default because reading debugfs and process metadata normally requires elevated privileges.
A clean result looks like this:
$ curl -fsSL https://raw.githubusercontent.com/vexxhost/nestedvirt/main/scripts/run-latest.sh | bash
Downloading nestedvirt v0.1.1 for linux/amd64...
nestedvirt_0.1.1_linux_amd64.tar.gz: OK
No nested virtualization usage observed.
Assessment:
Evidence: all observed KVM nested_run counters are zero.
Risk: no VM in this scan showed evidence that nested virtualization is required.
If nested virtualization has been observed, the output identifies the process and, when available, the VM identity:
Nested virtualization usage observed:
PID KIND PROCESS VM NOVA MONITOR NESTED_RUNS
2222 qemu qemu-system-x86 instance-0000002a (11112222-3333-4444-5555-666677778888) build-vm /var/lib/libvirt/qemu/domain-7-instance/monitor.sock 3
Assessment:
Evidence: one or more VMs have used nested virtualization.
Risk: disabling nested virtualization may break the VMs listed above.
For automation, JSON output is available:
curl -fsSL https://raw.githubusercontent.com/vexxhost/nestedvirt/main/scripts/run-latest.sh | bash -s -- --json
The command exits with 0 when no usage is observed, 1 when nested virtualization usage is observed, and 2 when the scan fails. That makes it usable in operational checks, maintenance workflows, and fleet reporting jobs.
How to Use the Result
nestedvirt is designed to help gate a nested virtualization policy change. It does not replace kernel patching, and it does not decide policy by itself.
If no nested virtualization usage is observed across the relevant hosts, that is useful evidence that disabling nested virtualization is less likely to break currently running workloads. Operators can use that result to proceed with a controlled change, ideally after scanning over a representative workload window.
If usage is observed, the listed VMs should be treated as workloads that may depend on nested virtualization. For OpenStack environments, the Nova metadata can help identify the server and owner. For non-OpenStack KVM environments, the QEMU process, VM identity, monitor socket, and PID still provide a concrete starting point for investigation.
The practical decision pattern is:
- patch affected KVM hosts as the primary remediation path;
- use
nestedvirt to identify current nested virtualization usage before disabling VMX or SVM exposure; - avoid blanket changes on hosts where active usage is observed unless the affected workloads have been migrated, remediated, or explicitly accepted;
- repeat scans after migrations, reboots, or workload changes.
Important Limits
A nested_run counter is runtime evidence, not a permanent inventory system.
The counter reflects the lifetime of the current KVM VM process. If a VM was recently restarted, recreated, migrated, or evacuated, the counter may be back at zero even if the workload historically uses nested virtualization. A zero result should therefore be read as "no nested virtualization usage was observed for the currently running VM lifetime during this scan," not as proof that the workload will never require nested virtualization.
The opposite case is stronger. A non-zero counter means the VM has used nested virtualization on that host during its current lifetime. That does not prove the workload has a contractual requirement forever, but it is strong enough evidence that disabling nested virtualization may cause an outage or behavioral change for that VM.
For high-confidence decisions, scan repeatedly over the operational window that matters: after workloads have settled, before and after maintenance events, and across the compute hosts where the policy change will be applied.
What This Means for KVM Operators
The larger lesson from CVE-2026-53359 is that virtualization security response cannot stop at package version checks. Operators also need to understand which features are exposed to guests and which guests are actually using those features.
nestedvirt gives KVM operators a focused way to answer one of those questions. It works for OpenStack Nova compute nodes, but it is not limited to OpenStack. Any Linux host running KVM with accessible debugfs and procfs can use the same counter-based approach to detect current nested virtualization usage.
For organizations deciding whether to temporarily disable nested virtualization, that turns an uncomfortable assumption into an evidence-backed change gate.
Kernel updates remain the durable fix. Detection helps operators make the interim decisions with fewer surprises.
We will continue to refine the tooling and guidance as distribution fixes, OpenStack mitigation patterns, and operator feedback evolve.
