What is nested virtualization and why it matters for VPS users

You are running a VPS, and suddenly you need a second hypervisor inside it. Maybe you want to test Proxmox before buying a dedicated server, or you need a clean Docker environment that itself runs containers. That is nested virtualization, running a VM inside a VM, and on most cheap VPS plans it simply does not work. The hypervisor inside your guest cannot see the virtualization instructions it needs. This post explains what nested virtualization actually is, why it matters for VPS users in 2026, where it breaks, and how to check whether your provider supports it.

Key takeaways

• Nested virtualization is running a hypervisor inside a VM, which requires the host CPU to expose VT-x/AMD-V to the guest.
• KVM-based VPS providers like thueVPS can enable nested virtualization, but most do not because it costs host performance and sandbox isolation.
• The performance penalty is real, typically 20-40% for CPU-bound workloads inside the nested layer, so budget accordingly.
• Containers (Docker, LXC) are not a substitute, but they cover many of the same use cases without needing nested virtualization at all.

嵌套虚拟化让你在 VPS 内运行虚拟机，但需要宿主机开启 CPU 虚拟化支持。

Nested virtualization lets you run VMs inside a VPS, but only when the host exposes CPU virtualization support to the guest.

Prerequisites

Before you try anything in this article, make sure your environment actually qualifies. Nested virtualization is not something you can enable from inside your own server; it depends entirely on the host.

• A KVM-based VPS. OpenVZ and LXC containers almost never support it.
• CPU virtualization flags exposed to your kernel, check with grep -c vmx /proc/cpuinfo (Intel) or grep -c svm /proc/cpuinfo (AMD).
• Root access, full root, not a semi-managed control panel user.
• RAM headroom. A nested VM doubles the memory overhead per guest.
• A provider that does not block the relevant kernel modules, kvm_intel or kvm_amd.

If you are renting a Linux VPS and the CPU flags are missing, no software trick will fix it. You need a different provider or a dedicated server.

What nested virtualization actually is

Nested virtualization is running a hypervisor inside a virtual machine. The outer hypervisor (the one your provider runs) creates a VM, and inside that VM you install another hypervisor, KVM, Proxmox, or even Hyper-V on a Windows VPS, which then creates its own VMs. The inner hypervisor thinks it is running on bare metal, but it is actually talking to virtualized CPU features.

For this to work, the outer hypervisor must pass the CPU virtualization instructions (Intel VT-x or AMD-V) through to the guest. Most hypervisors mask these instructions by default because exposing them weakens isolation and costs performance. When the flags are masked, the inner hypervisor cannot start any VM. It will either refuse to load the KVM module or fall back to an emulator like QEMU's TCG, which is so slow it is useless for anything real.

The technology has matured a lot since the early attempts. Modern KVM on a recent kernel handles nested virtualization with a fraction of the overhead that older versions had. As of 2026, with a current Linux kernel and a recent Intel or AMD CPU, the performance loss for the second layer sits around 20-40% for CPU-bound work, and it is noticeably worse for heavy I/O. This is not a trick; it is a real feature that some providers enable and most do not.

Why VPS users actually need it

The most common reason is testing. You want to evaluate Proxmox or oVirt without buying a dedicated server first. A VPS with n8n preinstalled or a plain KVM box with enough RAM becomes a sandbox where you can break things, rebuild clusters, and learn without risking production. When you are done, you reinstall the OS and start over.

The second common reason is isolation for clients. Freelancers and small agencies rent a VPS, then create separate VMs for each client so one compromised site cannot touch the others. This is heavyweight compared to containers, but it mirrors what you would do on a physical server, and some compliance requirements actually want VM boundaries, not container boundaries.

The third reason is running a container host. A VPS with nested virtualization makes a fine Docker host because Docker itself does not need the inner KVM layer; the VMs it manages do. In practice, most people run Docker directly on a VPS without nesting at all. If your only goal is containers, skip nesting entirely and save the overhead. If your goal is a lab that mimics a multi-node cluster, nesting is the only option short of a dedicated machine.

How to check if your VPS supports nested virtualization

Do not ask support first. Check yourself, it takes thirty seconds. Log in and run this:

grep -cE 'vmx|svm' /proc/cpuinfo
lsmod | grep kvm

The first command counts CPU cores that expose virtualization flags. If the output is 0, nested virtualization is not available, full stop. If it is a number greater than zero, try loading the KVM module and creating a test VM. The second command confirms the module is loaded. If lsmod shows nothing, try modprobe kvm_intel or modprobe kvm_amd, depending on your CPU.

Even when the flags are visible, the provider may throttle the nested layer. Some hypervisors expose the flags but set a CPU model that makes the inner hypervisor behave oddly. The real test is creating a VM inside your VPS and running a CPU benchmark inside that VM. Use sysbench for a quick check:

sysbench cpu run --threads=4

Run this once on the host and once inside your nested VM. If the nested result is more than 50% slower, your provider technically supports nesting but it is not practical for real work. If the module will not load or the flags are missing, the answer is no, and no configuration change will fix it.

Performance cost: what the numbers really say

Nested virtualization is not free. The outer hypervisor already adds a small tax, usually around 5-10% for KVM with modern hardware. The inner hypervisor adds another layer of the same tax, and that is where the 20-40% figure comes from. For a lab or a test environment that is fine. For production, it is a hard sell unless you have no other option.

Memory is the bigger problem. A 4GB RAM VPS that runs a nested hypervisor loses memory to the host OS, the outer hypervisor overhead, the inner hypervisor, and then each inner VM needs its own allocation. In practice, a 4GB VPS can run one small nested VM with 2GB of RAM and little else. An SMTP VPS or a modest web server does not need nesting at all, and you should not buy extra RAM just for it.

Disk I/O takes the hardest hit. Nested VMs on the same physical disk cause write amplification, and on a busy host the inner VM's I/O latency can double. If your workload is database-heavy, nesting will hurt. If it is CPU-light and network-light, the penalty is acceptable. Know your workload before you commit.

Docker is not nested virtualization, and that is fine

A frequent point of confusion: Docker and LXC are containers, not virtualization. They share the host kernel, so they do not need VT-x or AMD-V at all. You can run dozens of containers on a VPS that has zero virtualization flags. This is why WordPress VPS setups and n8n deployments use Docker without ever thinking about nesting.

Containers are lighter. A container adds almost no idle memory, while a VM reserves its full allocation upfront. A 2GB RAM VPS can run dozens of containers but only one or two small VMs. For most production workloads, containers are the correct answer, and nested virtualization is the escape hatch for the cases containers cannot cover.

The cases that need real VMs: running a different kernel than your host, testing a hypervisor itself, or satisfying a compliance rule that requires hardware virtualization boundaries. For everything else, containers win. Do not buy a nested-capable VPS just to run Docker; you are paying for a feature you will not use.

Which thueVPS plans make sense for nested workloads

thueVPS runs KVM virtualization with NVMe storage, and the KVM layer is the one that matters. If you want nesting, you need a plan with enough RAM to lose some to the inner hypervisor. A 2GB RAM VPS is too tight; you would be left with nothing for the inner VMs. A 4GB plan is the realistic entry point, and an 8GB plan is where a nested lab becomes comfortable. The VNx4 and VNx8 tiers fit this shape, and being on NVMe keeps the I/O penalty from becoming unbearable.

Pricing for these plans runs from around $8/mo for the 4GB tier up to about $18/mo for the 8GB tier, and you pay monthly, which matters because a nested lab is usually a temporary thing. VPS pricing changes over time, so check the current page before you commit.

Before you order, ask support one direct question: is nested virtualization exposed on the KVM layer? If the answer is yes, confirm it with the checks in this article the moment you get root. If the answer is no or if you get a runaround, treat it as no and plan for containers instead.

Nested virtualization vs a dedicated server

If your nested workload is a recurring need, not a one-time test, a dedicated server is often the smarter buy. A dedicated server Vietnam gives you the real CPU, the real RAM, and full control over the hypervisor, with zero nesting penalty. The cost is higher, but the performance ceiling is completely different.

The trade-off is flexibility. A VPS that supports nesting is cheaper and can be resized or rebuilt in minutes. A dedicated server requires a longer commitment and more planning. For a homelab or a learning environment, nesting on a VPS is the right call. For a production multi-tenant setup, either you are big enough for dedicated hardware, or you are big enough that the nested overhead is the least of your problems.

My rule of thumb: if the nested layer would run more than two VMs in production, get a dedicated server. If it is two VMs or fewer, or if it is a test environment, nesting on a VPS keeps your monthly bill low and your options open. There is no wrong answer, only the wrong tool for the scale you actually have.

FAQ

Related articles

• VPS vs dedicated server: which one do I need
• Run system containers with LXC and LXD on a VPS
• Set up a lightweight Kubernetes cluster with k3s on a VPS
• Install Docker on an Ubuntu VPS