Understanding Multi-Cloud Deployment with Nested Virtualization

Vantisso has exactly one prerequisite for starting a MicroVM: the host has to be able to use /dev/kvm. On a physical server that is a given. But a cloud instance is already a virtual machine. Can you run a virtual machine inside a virtual machine? The technology that answers this question is nested virtualization.

L0, L1, L2 — what it means to add a layer

Nested virtualization is exactly what the name suggests: stacking one more layer of virtualization, running a virtual machine inside another virtual machine. It helps to picture the virtualization stack as three layers.

Ordinary virtualization consists of two layers, L0 and L1. A cloud provider's compute instance is a virtualized instance (L1) created on top of a physical server (L0). Nested virtualization goes one step further and runs another virtual machine (L2) inside that instance. From Vantisso's point of view, the deployment host is the L1 cloud instance, and the MicroVMs Vantisso creates inside it sit at L2.

The catch is that running a virtual machine requires access to the CPU's hardware virtualization features, and cloud instances (L1) have traditionally not exposed those features to the guest OS. Inspecting CPU information inside an instance would turn up no vmx or svm flag, which meant KVM was unavailable there.

Fortunately, the major cloud providers have begun to support nested virtualization. Technically, this means the hypervisor at L0 passes the hardware virtualization features (VT-x/AMD-V) through to the L1 instance. The vmx or svm flag then becomes visible inside L1, /dev/kvm becomes usable, and you can create virtual machines inside that instance much as you would on a physical server. This is the key that makes it possible to deploy Vantisso on an ordinary VM instance instead of renting an expensive bare metal one.

The hardware mechanism behind nesting

In ordinary virtualization with no L2, a privileged operation attempted by the L1 guest OS triggers a VM Exit, and the L0 hypervisor handles it on its behalf. Nested virtualization stacks that structure one layer deeper. When the guest OS of an L2 MicroVM attempts a privileged operation, the L1 hypervisor (KVM) has to handle it — but L1 is itself a virtual machine, so its attempt to act as a hypervisor is in turn subject to L0's control.

What matters most in this nested handling is the multiplication of memory address translation. Modern CPUs accelerate the translation of guest virtual addresses into physical addresses in hardware; Intel calls this EPT (Extended Page Tables) and AMD calls it NPT (Nested Page Tables). Under nested virtualization this translation happens in two stages: L2 addresses into L1 addresses, then L1 addresses into L0 physical addresses. That multiplied translation is the main reason nested virtualization performs below bare metal.

Performance: where the cost actually lands

Multiplied address translation is not the only factor. Nested VM Exit handling matters too. An event raised at L2 has to pass through several layers to be handled, which inevitably costs more than single-layer virtualization.

Google Cloud makes this explicit in its documentation: even with hardware-assisted nested virtualization, nested VMs may see a performance decrease of 10% or more for CPU-bound workloads, and possibly greater than that for I/O-bound ones. AWS similarly advises evaluating bare metal instances for workloads that are performance sensitive or carry strict latency requirements.

The useful question is where that cost lands in an agent workload. Agent execution divides into two phases.

• Startup phase — disk provisioning, guest kernel boot, network allocation. This phase is I/O intensive, which is exactly where the nested virtualization penalty shows up most directly.
• Execution phase — the agent calls the model API, waits for a response, and carries out its work. Most of a task's total elapsed time is spent waiting on those responses, which leaves this phase relatively insensitive to CPU overhead.

In other words, what governs perceived performance in the cloud is the startup phase, and two responses are effective there. First, lean more heavily on snapshot restore and the warm pool: both skip guest boot and disk provisioning, so they are the least affected by nesting. Second, keep the golden image and the snapshot store on local NVMe or SSD-class disks. When I/O passes through two layers of virtualization, the choice of disk matters far more than it does on bare metal.

Bare metal is still the right answer for workloads that demand peak performance or strict latency. In many other cases, though, the performance loss from nested virtualization is a perfectly acceptable trade against the cost and minimum-size constraints of bare metal. For development and test environments, or for mid-sized production, running Vantisso on ordinary instances is considerably more economical.

Where the major clouds stand (as of July 2026)

Google Cloud has supported nested virtualization from early on and supports only Linux KVM as the L1 hypervisor, which makes it the most natural environment for Vantisso's Linux and KVM stack. The constraints are that it requires an Intel Haswell or later processor and is unavailable on AMD-based machine types.

Azure has also supported nested virtualization on certain VM families for years. Its focus, however, is on running Hyper-V natively, so it fits Windows Server-centric virtualization stacks more naturally. The detail that most often trips people up when using Linux KVM is the security type: an instance created with Trusted Launch has nested virtualization disabled, so it has to be created as Standard from the start.

AWS allowed nested virtualization only on bare metal for a long time, but since February 2026 it has been officially supported on C8i, M8i, and R8i instances. The Nitro System passes processor extensions such as Intel VT-x through to the instance, and both KVM and Hyper-V are supported as L1 hypervisors. That opens a path to running Firecracker-based workloads on ordinary instances without paying for bare metal.

One caveat worth keeping in mind: cloud instance families and support policies change quickly. The information above reflects the time of writing, so before you deploy, check each provider's current documentation for which families support KVM-based nested virtualization.

A one-minute check before deploying

Once your instance is up, three lines will tell you whether it is an environment where Vantisso can run.

# 1. Are the CPU virtualization extensions visible inside the instance? (Intel: vmx, AMD: svm)
grep -Eo 'vmx|svm' /proc/cpuinfo | sort -u

# 2. Is the KVM module loaded?
lsmod | grep kvm

# 3. Does the KVM device file exist, and is it accessible?
ls -l /dev/kvm

If the first command returns nothing, nested virtualization is not enabled. Check whether the instance family is supported and whether the nested virtualization option — or the security type — was set correctly at creation. If all three return what they should, that instance can run Vantisso exactly as bare metal would.

Infrastructure that runs anywhere

Broken down by deployment environment:

• Bare metal — Hardware virtualization is available directly, so Vantisso runs without any nested virtualization support at all. A physical server in your own data center, a workstation in the office, a personal laptop: anywhere with direct access to a physical CPU will do. A developer experimenting with a multi-agent system on their own laptop is entirely workable.
• Cloud (IaaS) — Pick an instance that supports nested virtualization. Google Cloud, Azure, and AWS all support it, so you can deploy across several clouds without being tied to a single provider.

This flexibility comes from the fact that Vantisso's design does not depend on any particular environment. Its requirement is one standard condition: a Linux host with access to hardware virtualization. No managed Kubernetes, no provider-specific managed service, no dedicated hardware.

Having only one prerequisite makes a bigger operational difference than it might seem, because it means the deployment location can be chosen on cost, performance, and regional requirements rather than technical constraints. If data sovereignty rules require a particular country's region, pick an instance family there that supports nested virtualization; if costs need to come down, change providers. From an individual running it casually on a laptop to an enterprise operating at scale across multiple clouds, the same Vantisso behaves the same way.