Email Us |TEL: 050-1720-0641 | LinkedIn | Daily Posts
| Collaboration | Questions? | Monthly Letter | Monthly Blog | Our Partners |
Managing Containers and Virtual Machines from One CLI
Light container technologies provided near-instant boot times and minimal resource overhead by sharing the host kernel. On the other hand, traditional hypervisors offered complete kernel isolation and cross-platform flexibility at the cost of higher memory consumption and slower initialization. Operating both environments typically meant maintaining disparate toolchains, distinct network configurations, and separate storage mechanisms.
While both Incus and Proxmox VE (PVE) trie to solve the same core problem managing both system containers (LXC) and full virtual machines (QEMU/KVM) from a single platform they approach this goal from different design philosophies, architectures, and target use case/
Orchestration Engine vs. Turnkey OS
- Proxmox VE is a complete Linux distribution. Proxmox is built as a custom Debian-based operating system designed to turn bare-metal servers into hypervisors out of the box. It packages Debian, LXC, QEMU/KVM, Corosync, and its own web interface into a monolithic, integrated platform.
- Incus is a composable daemon and CLI. Incus is an application/service that runs on top of almost any existing Linux distribution (Ubuntu, Debian, Fedora, Arch, Alpine, etc.). It acts as a lightweight daemon (incusd) with a REST API and CLI tool (incus). You bring your preferred base host OS, and Incus runs as the compute orchestrator on top.
API-First CLI vs. Web-First Management
- Proxmox VE is web-centric. Proxmox is built around its Web GUI (PVE Web UI). While it has command-line utilities (pct for containers, qm for virtual machines, pvecm for clusters), these are distinct tools built for specific subsystems rather than a single unified client tool.
- Incus is API/CLI-centric. Incus provides a single, unified command-line interface (incus) for all operations managing containers, VMs, storage, and networking uses the exact same syntax. Everything in Incus flows through a single REST API, making remote execution, automation, and CI/CD integration good without needing a web interface (though third-party GUIs exist).
LXC and VM Handling Paradigms
- Proxmox treats containers and VMs differently in the CLI. In Proxmox, a container is created with pct create, whereas a VM is created with qm create. They have separate configuration files, separate parameter formats, and slightly different feature sets within the management layer.
- Incus treats containers and VMs identically in the abstraction layer. In Incus, an instance is an instance. You launch a container with incus launch images:ubuntu/22.04 my-container and a full virtual machine with incus launch images:ubuntu/22.04 my-vm --vm. They share the same profile system, storage syntax, network attaching logic, and lifecycle commands (start, stop, snapshot, migrate).
Clustering and Database Architecture
- Proxmox clusters rely on pmxcfs (a fuse-based cluster filesystem synchronized via Corosync). It is optimized for smaller to medium-sized clusters (typically 3 to 32 nodes) and requires dedicated, low-latency cluster communication networks to prevent quorum issues.
- Incus has a native distributed SQLite database (dqlite) driven by the Raft consensus algorithm embedded directly inside the incusd daemon. Any node in an Incus cluster can handle API calls, and the cluster scales without requiring an external cluster filesystem layer like Corosync.
One way to look at it is, Proxmox VE as an open-source alternative to VMware vSphere or Nutanix—a turnkey, appliance-like hypervisor with a web dashboard for managing infrastructure visually.
And Incus as a lightweight, public-cloud-style engine (similar to AWS EC2 or OpenStack primitives) running directly on bare-metal Linux—designed for developers and sysadmins who prefer fast CLI interactions, declarative profiles, scriptability, and minimal overhead.
The Daemon and the Unified REST API Architecture
Incus architecture is a single background service, incusd, written in Go. This daemon is responsible for managing the entire lifecycle of all instances, storage pools, network interfaces, and security policies on a host system. Rather than tying management logic directly to the command-line client, Incus exposes all functionality through a clean, event-driven REST API.
The Incus command-line tool (incus) acts purely as a REST client. Whether you execute commands locally over a Unix domain socket or remotely over an encrypted TLS connection, the underlying API endpoints remain identical. This design decouples the user experience from the physical location of the hypervisor host. A developer working on a laptop can execute the exact same commands against local containers, a remote bare-metal server, or a distant multi-node cluster, operating with full feature parity without needing extra middleware or management plugins.
Container and Virtual Machine Runtime Engines
Incus presents a uniform management interface to the user, it intelligently drives two distinct underlying runtime engines to launch workloads depending on the required isolation level.
When launching a system container, Incus interfaces directly with liblxc to leverage native Linux kernel features such as namespaces, control groups (cgroups), and seccomp filtering. System containers simulate a complete Linux operating system including systemd init processes, system logs, and background services while sharing the host kernel. Incus emphasizes security by default, running containers as unprivileged instances using user namespace mappings. This maps root inside the container to an unprivileged user ID on the host host system, dramatically reducing the risk of container breakouts.
When full hardware isolation or a non-native kernel is required, Incus switches its backend driver to QEMU and KVM hardware virtualization. To maintain operational consistency, Incus embeds a lightweight helper utility, incus-agent, inside the virtual machine guest image. This agent communicates back to the parent incusd daemon, enabling features like file transfers, live executive console attachment, and guest system metrics collection. Because Incus handles the QEMU command-line flags and driver instantiations internally, users can spawn a fully isolated Linux or non-Linux virtual machine using the exact same CLI command structure used for containers, simply appending a flag to designate VM mode.
Storage and Network Abstraction Layers
An architectural strength of Incus is its ability to share storage backends and networking topologies across both containers and virtual machines without requiring custom hardware configurations.
The Incus storage driver abstraction layer supports multiple enterprise backends, including ZFS, Btrfs, LVM, raw directory structures, and distributed Ceph storage. Storage pools are defined independently of the compute workloads. When an instance is launched, Incus automatically provisions storage volumes according to the driver capabilities utilizing copy-on-write dataset cloning for ZFS or Btrfs, or thin-provisioned logical volumes for LVM. This design allows instant snapshotting, fast template cloning, and easy live migration of both containers and virtual machines across physical storage nodes.
Networking in Incus follows a similarly abstract model. Administrators can create native Linux bridges, Open Virtual Network overlay networks, or macvlan configurations. Incus automatically manages DHCP allocation, DNS resolution, and firewall rules for connected instances. Devices such as network interface cards, physical GPUs, USB devices, or raw disk paths can be dynamically attached or hot-plugged into running instances using uniform API calls, whether the target guest is running inside a lightweight system container or inside a QEMU virtual machine.
Profile-Based Configuration Management
Declarative configuration management is embedded into the Incus architecture through the use of profiles. Profiles act as reusable configuration templates that specify resource limits, attached devices, storage pools, environment variables, and network connections.
Multiple profiles can be cascaded and applied to an instance at launch or updated while the instance is running. For example, a default profile might define standard network bridging and primary storage pool attachments, while a secondary profile imposes memory limits, CPU pinning constraints, or custom firewall configurations. Because profiles apply transparently across both system containers and virtual machines, operations teams can enforce security baselines and resource quotas across heterogeneous compute workloads without writing bespoke scripts for different hypervisor tools.
Distributed Clustering and High Availability
Incus scales from a single developer machine up to massive enterprise data center clusters. That is different from traditional virtual machine managers that rely on enterprise cluster managers like Corosync or Pacemaker, Incus features a native, built-in distributed architecture.
An Incus cluster consists of multiple physical nodes connected together to share a single unified view of the environment. Cluster state is synchronized using an embedded relational database engine driven by the Raft consensus algorithm. This distributed transactional database ensures strong consistency across all cluster nodes without single points of failure. When managing a cluster, any node can receive CLI requests and route operations to the target host transparently. If a node fails, Incus can automatically rebalance or restart high-availability workloads on healthy remaining nodes, providing infrastructure resilience with minimal operational overhead.