Daily Post July 30 2026
Email Us |TEL: 050-1720-0641 | LinkedIn | Daily Posts
| Collaboration | Questions? | Monthly Letter | Monthly Blog | Our Partners |
Nested virtualization
The idea of running a hypervisor or container daemon within a virtual machine that is itself hosted by a physical hypervisor can sounds like an unnecessary, inception-like engineering experiment. But, when applied to running Incus inside a Proxmox Virtual Environment virtual machine, nested virtualization becomes very useful. design pattern for infrastructure. Proxmox VE acts as the foundational, bare-metal hypervisor, providing management for physical compute, storage, and networking. Inside a Proxmox-managed Linux VM, Incus operates as a secondary, lightweight container and VM daemon. Combining these two systems creates a layered architecture that solves operational challenges.
To understand why an enterprise would adopt this pattern, it is helpful to think about the architectural strengths of both platforms. Proxmox is good at macro-level infrastructure management. It handles bare-metal hardware integration, high-availability clusters, storage backends like Ceph and ZFS, and physical network bridging with ease generally. On the other hand, Incus is good at micro-level orchestration. It allows administrators to spin up dozens or hundreds of lightweight system containers or virtual machines in seconds via a fast REST API and CLI.
Isolation and Security
One of the primary values this architecture offers businesses is safe, multi-tenant isolation for development and testing environments. In a traditional setup, giving developers access to run container orchestration software directly on physical hypervisors presents security and operational risks. System-level container engines require broad privileges on the underlying Linux kernel, creating a broad attack surface. Provisioning a dedicated Proxmox VM for a software team and installing Incus inside it, the enterprise constructs a strong hardware-virtualized boundary around that team's entire workspace.
Density and Resource Efficiency
This nested approach dramatically improves resource efficiency and density for large-scale application workloads. Virtual machines generated by traditional hypervisors carry notable overhead because each requires a full OS kernel and dedicated hardware emulation. If an enterprise needs to deploy fifty isolated microservices or developer sandboxes, running fifty separate Proxmox VMs consumes substantial memory and CPU overhead. Running a single, well-resourced Proxmox VM and deploying fifty Incus system containers inside it, the enterprise leverages container-level kernel sharing. Incus containers launch almost instantaneously and share the underlying VM kernel, allowing businesses to achieve massive consolidation ratios while preserving isolated execution environments.
Networking, Auditing, and Infrastructure Portability
Network segmentation and security auditing also benefit significantly from this hybrid architecture. Proxmox allows network administrators to define precise virtual network interfaces, VLAN tags, and firewalls at the hypervisor level. The nested Incus installation inherits this parent VM network interface, allowing it to act as an isolated internal network bridge for all nested containers. This structure simplifies compliance and policy enforcement. Security teams can enforce firewall rules and monitor traffic at the Proxmox layer without needing to manage the dynamic, high-churn network interfaces created internally as Incus containers are added and removed.
Finally, running Incus inside a Proxmox VM offers infrastructure portability and simplified disaster recovery. A Proxmox VM housing an entire Incus environment along with its containers, storage pools, and configuration profilescan be backed up, snapshotted, and live-migrated as a single, unified virtual disk. If a physical bare-metal server needs maintenance, administrators can migrate the parent Proxmox VM to another node in the cluster without needing to export or re-orchestrate individual Incus containers. This abstraction layer bridges the gap between traditional enterprise virtualization and cloud-native container workloads.
The reason you put Incus inside Proxmox and almost never Proxmox inside Incus
It is because of how they handle physical hardware, kernel access, and bare-metal orchestration. Proxmox VE is a complete bare-metal operating system built directly on Debian Linux. Its primary job is to manage physical server hardware RAID cards, network interface controllers (NICs), physical RAM, storage pools (like ZFS or Ceph), and CPU virtualization extensions (Intel VT-x / AMD-V).
Incus, is capable of managing full virtual machines via QEMU, was built from LXD as a container/VM manager meant to sit on top of an existing Linux kernel.
If you try to put Proxmox inside an Incus VM:
- Hardware passthrough becomes a mess Proxmox expects raw, low-level control of storage and networking to manage clusters, storage pools, and firewalling. Inside an Incus VM, it gets an emulated, virtualized layer instead of real hardware, severely limiting its core capabilities.
- Double virtualizing for no reason Proxmox’s main strength is managing physical nodes and storage clusters. Strip away its access to physical hardware, and you lose most of why Proxmox exists in the first place.
Putting Incus inside Proxmox works because Proxmox provides the physical foundation.
Production Incus vs. Production Proxmox
Incus isn't a scaled-down tool; it’s designed for heavy production lifting. It handles both LXC system containers and full QEMU virtual machines, features native clustering, storage abstraction (ZFS, Ceph, LVM), and precise resource controls.
When you compare them in production
- Proxmox gives you a complete, GUI-centric bare-metal hypervisor appliance with integrated cluster management, high availability, and out-of-the-box storage handling.
- Incus gives you a light, API-native operational model with near-zero overhead for system containers and fine-grained control via CLI.
When you run production Incus inside a Proxmox VM, you aren't doing it to make Incus "safe" for production you're doing it to combine two different layers of production infrastructure management.
Unified Bare-Metal Management
In a production datacenter, you often have legacy VMs, Windows servers, full Linux virtual machines, and lightweight Incus instances.
- If you run Incus directly on bare metal across your fleet, you have to manage physical hardware monitoring, storage arrays, network switches, and host backups for those Incus hosts separately from the rest of your virtualization estate.
- Using Proxmox as the bare-metal hypervisor layer across all physical nodes, Proxmox handles the raw hardware, Ceph/ZFS storage pools, physical networking, and hardware alerts. Incus runs inside dedicated production VMs on top of that stable base
Infrastructure-as-a-Service and Multi-Tenant Fleet Division
If you operate as a service provider or run multiple internal production business units, you don't always want a single massive Incus cluster sharing one kernel or network boundary across all tenants.
Deploying production Incus daemons inside Proxmox VMs, you can carve up your physical hardware into isolated production tiers:
- Production Tier A: Lives in a multi-node Incus setup inside dedicated Proxmox compute resources with guaranteed CPU/RAM pinning.
- Production Tier B: Runs in a separate Proxmox VM or directly on Proxmox, completely isolated at the hardware boundary level from Tier A.
Hypervisor-Level Backup and Disaster Recovery
Incus has great internal snapshotting and image export capabilities, taking a full, crash-consistent backup of a production environment at the hypervisor level adds a layer of safety.
- A Proxmox VM running a production Incus instance can be backed up using Proxmox Backup Server with block-level deduplication, incremental backups, and live encryption.
- If a production disaster strikes (like a corrupted host OS database or broken storage pool configuration inside the VM), you can restore the entire operating system and its active Incus daemon to any physical Proxmox host in minutes.
Zero-Downtime Hardware Maintenance
If a physical server hosting your production environment needs a BIOS update, RAM replacement, or kernel patch:
- Proxmox handles live migration of the parent VM to another physical host in the Proxmox cluster without taking the nested production Incus containers down.
- You maintain high availability at the physical hardware level without having to re-route or fail over the internal Incus network.