What virtualisation actually does

Why this matters in production

Every troubleshooting session that follows assumes you understand what actually happens when a guest “runs.” A performance investigation that misidentifies the virtualisation layer can waste hours. A security model that assumes a container is equivalent to a VM can leak credentials. This lesson builds the mental model everything else rests on.

Mental model

A virtual machine is not magic. It is a process on the host operating system that has been given privileged access to hardware virtualisation features, plus a set of emulated or paravirtualised devices. A container is a process on the host whose visibility of the system has been restricted using kernel namespaces and cgroups.

The diagram below shows the four layers any guest workload sits on, in Proxmox:

flowchart TB
  A[Guest OS / apps] --> B[Emulated or paravirt devices]
  B --> C[Hypervisor: QEMU + KVM]
  C --> D[Linux host kernel]
  D --> E[Physical hardware: CPU, RAM, NIC, disk]

Two important consequences:

1. The host kernel is in charge. A guest kernel call that never leaves the guest is fast. A call that traps into the host (an I/O operation, a privileged instruction, a clock read) pays a cost.
2. Devices are not real. A “disk” the guest sees is a file, an LVM volume, a Ceph RBD, or a network block device on the host. When the guest writes to it, the host kernel writes to something else first.

Concepts

Emulation

The guest’s CPU instructions are translated to the host’s CPU one by one. Used by QEMU when no hardware virtualisation is available, or when emulating a different architecture (e.g. running an ARM guest on an x86 host). Slow. Almost never what Proxmox does for production VMs.

Full virtualisation with hardware assist

The guest’s privileged instructions trap into the host, which uses Intel VT-x or AMD-V to switch into a hardware-defined “guest mode.” The guest sees what looks like real hardware; the host intercepts only the operations that require privilege. This is what KVM does, and it is the default mode for Proxmox VMs.

Paravirtualisation

The guest knows it is virtualised. It calls the host through a defined interface (the VirtIO family of drivers) instead of pretending to talk to real hardware. Paravirtualised I/O is dramatically faster than emulated I/O; it is the recommended configuration in Proxmox.

Containerisation (LXC)

There is no second kernel. The guest shares the host kernel and uses namespaces to isolate what it can see. Resource limits are enforced by cgroups. There is no hardware-virtualisation boundary between the guest and the host kernel — the guest is one privilege escalation away from the host.

How Proxmox implements it

flowchart LR
  subgraph KVM[VM]
    K1[Guest kernel] --> K2[Guest userspace]
    K2 --> K3[QEMU process on host]
    K3 --> K4[Linux kernel + KVM module]
  end
  subgraph LXC[Container]
    L1[Container userspace] --> L2[Namespaces]
    L2 --> L3[Linux kernel + cgroups]
  end
  K4 --> H[Physical hardware]
  L3 --> H

The QEMU process is itself just a process. It can be paused, snapshotted, live-migrated, and killed — like any other process. That is why a Proxmox node can host hundreds of VMs and yet operations that would be impossible on bare metal (online migration, snapshotting a running guest) are routine.

Virtualised resources

CPU

Proxmox exposes vCPUs to the guest. The mapping to physical cores depends on the host kernel scheduler; the default is opportunistic time-slicing. Setting cpu: host exposes the host CPU features verbatim (best performance, no live migration between hosts with different CPUs); setting cpu: kvm64 or a named model (e.g. x86-64-v3) limits features for portability at a small performance cost.

Memory

Guest memory is host memory. The host cannot tell whether a page is in use; ballooning lets the guest return memory to the host dynamically. KSM (Kernel Same-page Merging) lets the host deduplicate identical pages across guests — useful for fleets of similar VMs, but watch the CPU cost.

Storage

The guest sees a virtual disk. On the host, that disk is one of:

• A file on a filesystem (qcow2, raw)
• An LVM logical volume
• A ZFS zvol
• A Ceph RBD image
• An iSCSI LUN mounted on the host and exposed to the guest

The choice has profound performance and operational consequences, covered in Parts V–VIII.

Network

The guest sees a virtual NIC. On the host, traffic flows through a tap device into a Linux bridge, then out whatever physical interface the bridge is bound to. SDN zones add another layer (Part IV).

GUI walkthrough

The decision “VM or container?” appears in two places:

1. Create → VM (top right of the GUI, “Create VM” button). Choose between:
   • BIOS: legacy boot, simpler, fewer features.
   • UEFI: required for Secure Boot, TPM, disks > 2 TiB without MBR/GPT quirks.
2. Create → CT (the “Create CT” button). Container templates and OS templates are listed separately from VM ISOs.

CLI walkthrough

qm list

pct list

qm config 100

Important configuration files

The <vmid>.conf file is the authoritative source of truth for a VM’s hardware, options, and boot order. The GUI and CLI both read and write to it. There is no database behind it; it is a simple text file on a cluster filesystem (pmxcfs). That is what makes Proxmox config easy to back up, version-control, and audit.

Hands-on lab

Inspect the following snippet of a VM configuration:

boot: order=scsi0
cores: 4
cpu: host
memory: 8192
balloon: 1024
scsi0: local-zfs:vm-100-disk-0,discard=on,iothread=1,size=100G
scsihw: virtio-scsi-single
net0: virtio=00:50:56:00:00:01,bridge=vmbr0,firewall=1
machine: pc-q35-9.0

Answer:

1. How many vCPUs and how much RAM?
2. Is the balloon driver enabled? What does that mean for memory overcommit?
3. Which disk controller is in use? What is the storage backend?
4. Is this a VM or a container? Justify your answer.
5. Could this VM be live-migrated to another node? What would you need to check first?

(Answers are in the Verify your work section below.)

Verify your work

1. vCPUs: 4 (cores: 4). RAM: 8192 MiB (memory: 8192), with a 1024 MiB minimum under ballooning.
2. Yes — balloon: 1024 means the guest can shrink down to 1024 MiB if the host is under pressure. The hypervisor can reclaim up to (8192 − 1024) = 7168 MiB if needed.
3. scsihw: virtio-scsi-single (modern, paravirtual). Backend is local-zfs (a ZFS zvol).
4. VM. Container configurations do not have scsi0, cpu: host, or machine:. They use rootfs: and features: instead.
5. Migration is possible if the target node is in the same cluster, has access to the same local-zfs pool (or compatible shared storage), and the cpu: host setting can be downgraded — host cannot cross between nodes with different CPU feature sets unless both support the same feature flags. For a portable VM, use a named CPU model such as x86-64-v3-AES.

Break/fix exercise

A user reports that “the VM is slow.” You check top on the guest and see one CPU at 100 % while the host has pveperf output showing plenty of idle capacity. What layers might explain the discrepancy?

• The guest may be single-threaded by design (the application is not parallel).
• The host may be scheduling the guest’s vCPUs onto the same physical core (CPU pinning awareness).
• CPU features may differ (guest uses AES-NI, host drops the vCPU onto a core without it).
• The “100 %” CPU may be on the host’s KVM thread that services the guest — the guest itself may be idle waiting on I/O.

Production considerations

• Mix KVM and LXC intentionally. Containers for Linux services where density and fast provisioning matter; VMs for anything that needs a separate kernel, Windows, or stricter isolation. Never assume a container is “as safe” as a VM.
• Match the storage backend to the workload. A database that does 10 k IOPS will not be saved by a fancy CPU pinning exercise if it sits on a single SATA SSD.
• Watch the host’s view. pveperf and sar on the host reveal what the guest cannot see.

Common mistakes

• Treating containers as VMs. They share the kernel. A root-in-container compromise is a potential root-on-host compromise; never run untrusted code as root in an unprivileged container without further hardening.
• Setting cpu: host and assuming you can migrate freely. You cannot, unless every cluster node exposes the same features.
• Forgetting that the host kernel sees everything in an LXC container. The host kernel’s vulnerabilities are the container’s vulnerabilities.

Key takeaways

• Proxmox VMs run on QEMU/KVM with hardware-virtualisation assist and (typically) VirtIO paravirtual devices. LXC containers share the host kernel with namespace/cgroup isolation.
• “Type 1 vs Type 2” is a marketing distinction. The operational distinction is whether the guest has its own kernel.
• All configuration is plain text in /etc/pve/. This is a feature: back it up, version it, audit it.

Knowledge check