Virtualization

Before you read. A rack used to hold six servers doing six jobs, each one idle most of the time because you had to size it for its busiest hour.

Now it holds one server running six operating systems, each convinced it has a machine to itself. Each has its own kernel, its own disks, its own network card, its own reboot.

How can six operating systems each believe they own hardware that only one of them can be using at any instant?

By being lied to, convincingly, by something underneath them. And the interesting part is where that something lives, because on Linux it is not a separate product sitting below the operating system. It is the kernel you already have.

That fact is why virtualization on Linux looks the way it does, and it is what the first half of this lesson is about. The second half is containers, which solve a related problem in a completely different way, and the difference between them is one you can measure in a single command.

Some words you will need

hypervisor

The layer that presents fake hardware to several operating systems and shares the real hardware between them.

host

The physical machine and the software running the hypervisor.

guest

An operating system running on it, believing it has a machine.

image

A file on the host that the guest sees as a disk.

namespace

A kernel feature giving a process its own private view of something, process IDs, mounts, the network. What containers are built from.

What breaks without this

You cannot tell what you are on. Diagnosing a “failed disk” differently depending on whether it is a physical drive or a hypervisor volume is the difference between an engineer visit and a console click.

You size things wrong. A guest sees the CPU count it was given, not the host’s, and thin-provisioned disks can promise more space than exists.

You cannot reach the machine you built. VM networking has four modes and three of them produce a guest that works perfectly and cannot be reached from where you are sitting.

Type 1, type 2, and where KVM sits

KVM does not fit either box cleanly, and that is the interesting part. KVM is a kernel module. Load it and the Linux kernel becomes a type 1 hypervisor, while remaining an ordinary operating system you can log into and run things on.

So a Linux host with KVM is simultaneously a general-purpose OS and a bare-metal hypervisor, which is why “type 1 or type 2” is a question the exam asks and practitioners argue about. The expected answer is type 1, because the hypervisor is in the kernel with direct hardware access rather than a program running on top of it.

Three names that always appear together and do different jobs:

KVM makes the CPU fast; QEMU pretends to be the hardware around it; libvirt is what you actually type at. Without KVM, QEMU still works by emulating the processor too, which is dramatically slower, and is exactly what happens when you run an x86 image on an ARM machine.

Hardware virtualization must be enabled in firmware. Intel VT-x or AMD-V, frequently off by default on desktop boards. grep -E 'vmx|svm' /proc/cpuinfo returns nothing when it is disabled, and the symptom is a VM that runs at roughly a twentieth of the speed you expected.

Telling where you are

systemd-detect-virt reports what is virtualising the machine. Note that the command’s exit status is also printed.

# Fedora CoreOS 44.20260707.3.1 on a virtual machine, aarch64
$ systemd-detect-virt; echo "exit status $?"; echo "--- what does the firmware call this machine ---"; sudo dmidecode -s system-product-name
apple
exit status 0
--- what does the firmware call this machine ---
Apple Virtualization Generic Platform

systemd-detect-virt is the one-word answer. It names the hypervisor (kvm, vmware, microsoft, oracle, xen, or here apple) and exits non-zero on bare metal, which makes it the version to use in a script.

dmidecode -s system-product-name reads what the firmware claims, which is where the same answer comes from in a more verbose form. On a physical machine it names the model, and that is what a hardware vendor asks for.

systemd-detect-virt -c answers specifically “am I in a container”, and -v specifically “am I in a VM”, which matters because you can be in both.

Containers are not small virtual machines

This is the distinction the exam tests and the one worth being precise about.

# Debian 13 (trixie), x86_64
$ echo "--- markers a container leaves for itself ---"; ls -l /run/.containerenv /.dockerenv 2>/dev/null || echo "(no marker file)"; echo "--- and PID 1 is not systemd ---"; cat /proc/1/comm; echo "--- the kernel is the hosts ---"; uname -r
--- markers a container leaves for itself ---
-rw-r--r--. 1 root root 0 Aug  8 02:37 /run/.containerenv
--- and PID 1 is not systemd ---
sh
--- the kernel is the hosts ---
7.1.3-200.fc44.aarch64

They are not competitors. The normal arrangement is containers running inside virtual machines: the VM gives a hard boundary between tenants and the containers give density and fast deployment inside it. Every managed Kubernetes service is built this way.

virsh domiflist myvm            # which network is it actually on
ip -brief addr                  # did it get an address, and from where
bridge link                     # is the tap device enslaved to the bridge
ip route                        # does it have a default gateway

Disk images

A guest’s disk is a file on the host. Which format decides what you can do with it.

qemu-img creates and converts them, including between vendors:

qemu-img create -f qcow2 disk.qcow2 40G
qemu-img info disk.qcow2
qemu-img convert -f vmdk -O qcow2 old.vmdk new.qcow2

qemu-img convert between formats is how a machine moves between hypervisors, and it is worth knowing exists before somebody tells you a VMware guest cannot be migrated.

Thin provisioning is the qcow2 feature that matters and the one that bites. A 40 GB qcow2 occupies a few hundred kilobytes until the guest writes to it, and grows on demand. So you can create six 40 GB disks on a 100 GB host, which is convenient right up to the day the guests fill them.

The host running out of space pauses every guest at once. Guests do not see a disk error and handle it gracefully; they see writes stop. qemu-img info shows the difference between virtual size and actual size, and the sum of the virtual sizes against the host’s free space is a number worth monitoring.

Networking, and why the VM is unreachable

Four modes. Choosing wrong is the most common reason a new VM works perfectly and cannot be reached.

NAT is the default nearly everywhere, which is why this comes up so often. The guest reaches the internet, updates work, everything looks healthy, and nothing on the network can start a connection to it, because it is behind the host’s address on a private network that does not exist outside the host.

Bridged is what a server wants. The guest’s virtual interface is attached to the host’s physical one, it gets an address from the same DHCP server as everything else, and it is an ordinary machine on the LAN.

Two things that catch people with bridging: the host’s physical interface must be enslaved to a bridge, which briefly disconnects the host when you set it up; and some wireless adapters cannot bridge at all, because 802.11 does not carry arbitrary source MAC addresses. On a laptop, bridging over Wi-Fi fails for reasons that have nothing to do with your configuration.

virsh list --all                       # every guest and its state
virsh start web01 / shutdown / destroy # destroy is a power cut, not a delete
virsh undefine web01 --remove-all-storage   # this is the delete
virsh dumpxml web01                    # the guest's full definition
virsh edit web01                       # edit it, with validation
virsh console web01                    # serial console, when the network is gone
virsh net-list --all                   # the virtual networks
virsh snapshot-create-as web01 pre-upgrade

Across distributions

Podman is the RHEL family’s default and is daemonless and rootless by default, which is a genuine security difference from Docker rather than a branding one: there is no privileged daemon owning every container, and container root is an unprivileged host user.

Prove it

On a machine you have just been given:

# Am I on hardware, in a VM, or in a container
systemd-detect-virt
systemd-detect-virt -c && echo "in a container"

# If it is a VM, what is the hypervisor
sudo dmidecode -s system-product-name

# Can this machine host VMs at all
grep -c -E 'vmx|svm' /proc/cpuinfo
lsmod | grep kvm

# What is running
virsh list --all
qemu-img info /var/lib/libvirt/images/web01.qcow2

grep -c -E 'vmx|svm' /proc/cpuinfo returning 0 is the answer to “why is this VM so slow”. Hardware virtualization is disabled in firmware and QEMU is emulating the processor.

What trips people up

1. “Type 1 or type 2” for KVM

Type 1. It is a kernel module, so the hypervisor has direct hardware access, even though the same kernel is also running an ordinary operating system. The ambiguity is real and the exam’s answer is type 1.

2. The VM has an address and nobody can reach it

NAT. The guest is behind the host on a private network, so outbound works and inbound does not.

Switch to bridged for anything that must be reachable, or add port forwarding for a single service. virsh domiflist <guest> shows which network a guest is attached to.

3. Thin provisioning ran out

Six 40 GB qcow2 images on a 100 GB host is legal and works until the guests actually write. When the host fills, every guest pauses at once.

qemu-img info shows virtual against actual size. Monitor host free space, not guest free space. The guests will all report plenty.

4. virsh destroy when you meant to shut down

destroy is an abrupt power-off, not a deletion. It risks filesystem damage in the guest exactly as pulling the cord would.

virsh shutdown asks the guest to shut down cleanly, and needs the guest agent installed to work reliably. undefine is the one that deletes.

5. Expecting a container to behave like a VM

No init system, so no systemctl. No separate kernel, so no modprobe and no sysctl that survives. One foreground process, and when it exits the container stops.

A container that “will not stay running” is nearly always a process that daemonised itself into the background, leaving PID 1 with nothing to do.

Work it through

You are asked to run a legacy application on a new server. It needs CentOS 7, kernel 3.10, and a specific out-of-tree storage driver. The new host runs a current RHEL-family release. Somebody suggests “just containerise it”.

Reason it out before reading on.

Containers cannot do this, and the reason is specific. A container shares the host’s kernel. The application needs kernel 3.10; the host is running something far newer. There is no configuration that changes this, because the container has no kernel of its own to configure.

The uname -r capture earlier is the proof: a Debian container on a Fedora host reports Fedora’s kernel. A CentOS 7 container on this host would report the host’s kernel, and the application would be running on exactly the kernel it cannot run on.

The out-of-tree driver settles it twice over. Kernel modules are loaded into the host kernel and are global. A container cannot load one, and if the host loaded it, it would have to be built for the host’s kernel, which is lesson 10’s vermagic rule, and which defeats the purpose.

So it needs a virtual machine. Its own kernel, its own module, its own boot.

virt-install --name legacy-app --memory 8192 --vcpus 4 \
  --disk path=/var/lib/libvirt/images/legacy.qcow2,size=100,format=qcow2 \
  --network bridge=br0 \
  --os-variant centos7.0 \
  --location /iso/CentOS-7.iso

Bridged, because it is a server other things must reach. qcow2, for snapshots before you touch anything. --os-variant because it makes libvirt choose sensible virtual hardware for that guest, and getting it wrong is a common cause of poor performance.

Then the things that are easy to skip. Install the guest agent so the host can shut it down cleanly and snapshot it consistently. Snapshot before installing the driver. And write down that this guest exists and why, because a CentOS 7 machine is now an unpatched machine and that is a decision somebody should have made deliberately.

Now the point worth extracting. “Containerise it” is a good instinct and the wrong tool here, and the reason is one question: does this workload need its own kernel?

If yes (a different OS, a different kernel version, a kernel module, a real isolation boundary between tenants) it is a virtual machine, and no amount of container tooling changes that.

If no (it is an application that runs on this kernel and you want many of them, started quickly, packaged with their dependencies) it is a container, and a VM is wasteful.

That one question answers it nearly every time, and it is why the uname -r capture is the most useful thing in this lesson.

Try it

Optional. Most of this needs a machine that can host VMs, which a virtual machine usually cannot.

1. systemd-detect-virt on everything you have access to. Note which report bare metal.
2. grep -c -E 'vmx|svm' /proc/cpuinfo. Zero means hardware virtualization is off in firmware.
3. sudo dmidecode -s system-product-name and compare with what you expected.
4. In a container, podman run --rm -it debian bash, run uname -r and compare it with the host’s. Then cat /proc/1/comm.
5. lsns on a host running containers, and find the extra namespaces.
6. If you have a KVM host: virsh list --all, then qemu-img info on an image and compare virtual size with actual size.

Verification step. You have it when you can be handed a workload and decide between a container and a VM by answering one question, and say what the question is.

Check yourself

References

Pictures. The Cockpit screenshot was taken on a machine of mine rather than copied from anywhere. Cockpit is free software from the Cockpit project, published at cockpit-project.org under LGPL v2.1 or later, and a screenshot of it carries that licence. The browser chrome is cropped off and it is resized; nothing else is altered.

• virsh(1) - libvirt project. Accessed 2026-08-07.
• libvirt networking - libvirt project. Accessed 2026-08-07.
• qemu-img - QEMU project. Accessed 2026-08-07.
• systemd-detect-virt(1) - Linux man-pages project. Accessed 2026-08-07.
• KVM in the kernel documentation - The Linux Kernel documentation. Accessed 2026-08-07.
• namespaces(7) - Linux man-pages project. Accessed 2026-08-07.

The virsh, qemu-img, and virt-install commands here are from libvirt’s and QEMU’s own documentation rather than captured, because the podman machine cannot host virtual machines of its own, nested virtualization is exactly what this topic explains is unavailable. The detection captures are real. Blocks without a distribution and architecture header are illustrative.