How virtualization works, and what your host can do

Why this matters

Every server you have administered so far arrived already built. Somebody decided how much memory it had, what its disk was really made of, which network it sat on and whether anything was protecting it. From this lesson on you are the person who decides, because you are on the host.

The first question on any host you inherit is not "what is running here". It is "what can this machine actually do for its guests" — because the answer changes what you may promise. A host with hardware acceleration runs guests at close to the speed of the processor underneath. A host without it still runs them, faithfully and slowly, by translating every instruction in software. Both are useful. Confusing them is how people end up quoting a benchmark from a laptop to a customer buying a server.

There is a second reason to start here. The tools disagree with each other. One of them looks at a device node, one reports what it probed when it started, and one is the only thing that actually tries. Knowing which to believe is a small skill that saves a long afternoon.

Concepts

A hypervisor is the thing that gives a guest a processor, memory and devices, and keeps it out of everything else. Textbooks divide hypervisors into type 1 (on the hardware) and type 2 (on an operating system). On Linux that line is blurred on purpose: KVM is a kernel module, so the moment it is loaded, the Linux kernel *is* the hypervisor. Your host is not "Linux running a hypervisor". It is a hypervisor that also runs your shell.

The processor does the hard part. Intel VT-x and AMD-V add a mode in which guest instructions run directly on the processor while the hypervisor keeps control of the things a guest must not touch. KVM drives that mode through /dev/kvm. When it is available, a guest's ordinary instructions cost almost nothing.

QEMU provides everything that is not the processor. It emulates the chipset, the disks, the network cards, the serial port and the firmware; it is the program you actually see in ps when a guest is running. QEMU can also emulate the processor itself, in software, with a translator called TCG. That is the fallback when there is no KVM: correct, complete, and perhaps ten to twenty times slower.

virtio is the deal you strike with the guest. Emulating a real network card means pretending to be hardware nobody needs any more, one register at a time. A virtio device is a paravirtual device: the guest knows it is virtual and talks to the host over a shared ring buffer. Every guest in this course uses virtio for its disk and its network card, and it is the default you should reach for everywhere.

libvirt is the management plane. It stores guest definitions as XML, starts and stops them, manages storage pools and virtual networks, and offers one stable interface — virsh, an API and a socket — over QEMU and several other hypervisors. Proxmox VE, which Ultiblob's own platform runs on, is a different management plane over the same QEMU and the same KVM. Lesson 2 maps one onto the other.

Two hypervisors on one machine. libvirt runs a system-wide instance at qemu:///system, where the guests that matter live, and a per-user instance at qemu:///session for unprivileged desktop use. A non-root user's virsh talks to the session instance by default, which is why a new administrator's first virsh list is empty on a host full of guests. You fix that once, in ~/.config/libvirt/libvirt.conf.

Nested virtualization is running a hypervisor inside a guest — which is what your lab machine is. When the platform grants it, the inner guests are accelerated too. When it does not, they fall back to TCG.

What emulation does not demonstrate. Every command, every configuration file and every failure mode in this course behaves identically under emulation. Timing does not. If your host emulates its guests, no number you measure here belongs in a sentence about performance, and this course will say so again where it matters.

Three ways to ask about acceleration, and which to believe

| Tool | What it actually checks | How it can mislead you | |---|---|---| | kvm-ok | the processor flags and whether /dev/kvm exists | a device node can exist with no working driver behind it | | virsh capabilities | what libvirt probed from QEMU when it started | it is a cache; it can be stale after a kernel or platform change | | opening /dev/kvm | whether the kernel will hand over the device — what QEMU does first | it is the truth, and it takes one line of shell |

While this lesson was being written, a host produced exactly that disagreement: /dev/kvm was present, kvm-ok reported "KVM acceleration can be used", and opening the device failed with No such device. The guests on that host ran perfectly well — emulated.

Guided exercise

You will work on your lab machine virt01 as the user ubuntu. It has sudo, and it is already a member of the libvirt group, which is what lets you manage system guests without becoming root for every command.

1. Sign in and look at what is there. Run virsh list --all. It prints an empty table. Nothing is wrong: you are talking to your own session instance, not to the host's.

``bash virsh uri

``text qemu:///session

1. Point virsh at the system hypervisor, permanently. The client library reads a small configuration file in your home directory, so this works in scripts as well as at the prompt.

``bash mkdir -p ~/.config/libvirt printf 'uri_default = "qemu:///system"\n' > ~/.config/libvirt/libvirt.conf virsh uri

``text qemu:///system

1. Confirm the management service is running. This is the daemon every later lesson talks to.

``bash systemctl is-active libvirtd

1. Ask libvirt what it is. virsh version names the library, the API and the hypervisor underneath.

``bash virsh version

``text Compiled against library: libvirt 10.0.0 Using library: libvirt 10.0.0 Using API: QEMU 10.0.0 Running hypervisor: QEMU 8.2.2

1. Ask about the hardware. virsh nodeinfo is the host's own hardware as libvirt sees it, and the first figure in any capacity arithmetic you will do later.

``bash virsh nodeinfo

``text CPU model: x86_64 CPU(s): 16 CPU frequency: 2399 MHz CPU socket(s): 1 Core(s) per socket: 8 Thread(s) per core: 2 NUMA cell(s): 1 Memory size: 32864316 KiB

Your numbers will differ; write down the ones you see, not the ones printed here.

1. Ask the three acceleration questions. Run all three and compare them.

``bash virsh capabilities | grep -o "domain type=.[a-z]*." | sort -u kvm-ok if [ -e /dev/kvm ] && (exec 3<>/dev/kvm) 2>/dev/null; then echo "/dev/kvm opens: acceleration is real"; else echo "/dev/kvm does not open: guests will be emulated"; fi

On the machine these notes were taken on, libvirt offered both domain types, which means acceleration is available:

``text domain type='kvm' domain type='qemu' INFO: /dev/kvm exists KVM acceleration can be used /dev/kvm opens: acceleration is real

If your host offers only the qemu domain type, or the device does not open, your guests will be emulated. Everything in this course still works; note it and carry on.

1. Look at the fuller picture once. virt-host-validate qemu checks a dozen things a hypervisor host wants, and explains each WARN rather than just failing. Read it, and notice that it too reports /dev/kvm as accessible on the basis of a check that is shallower than opening it.

``bash virt-host-validate qemu 2>&1 | head -6

1. Write the survey down. Create ~/notes/01-this-host.md with exactly these six fields, filled in from what you just ran, followed by a short conclusion in your own words:

```text # virt01 — what this host can do

• libvirt: 10.0.0
• hypervisor: QEMU 8.2.2
• CPUs: 16
• memory: 32864316 KiB
• acceleration: kvm (libvirt offers the kvm domain type on this host)
• kvm-ok said: INFO: /dev/kvm exists KVM acceleration can be used

```

Those are the values from the machine these notes were taken on. Use your own, in this exact shape: the libvirt "Using library" version, the "Running hypervisor" version, the processor count and memory size from nodeinfo, the word kvm or emulated with one sentence saying how you decided, and what kvm-ok printed. Finish the file with a short conclusion in your own words.

The check reads your file and compares it with what this host reports right now, so a survey copied from somebody else's machine fails.

Troubleshooting

Symptom: `virsh list --all` is empty although guests exist. You are on qemu:///session. Cause: a non-root user's default URI is their own instance. Fix: set uri_default as in step 2, or use virsh -c qemu:///system once, or export LIBVIRT_DEFAULT_URI.

Symptom: `error: failed to connect to the hypervisor … Permission denied`. Your account is not in the libvirt group, so it cannot open the read-write socket. Cause: group membership is what grants access to /var/run/libvirt/libvirt-sock. Fix: sudo usermod -aG libvirt $USER, then start a new session — group membership is read at login, so an existing shell will not see it.

Symptom: `kvm-ok` is cheerful but a guest defined with the `kvm` domain type refuses to start. Cause: the device node exists but the kernel will not hand it over — commonly because nested virtualization is not enabled for this machine, or a kernel upgrade has left a module unloaded. Fix: believe the failure, define guests as type='qemu' (lesson 3) and record the finding; it is a platform question, not a libvirt one.

Symptom: `virsh capabilities` says one thing, a guest does another. Cause: libvirt caches what it probed at start-up in /var/cache/libvirt/qemu. Fix: sudo systemctl restart libvirtd to re-probe, then compare again. If the answer changes, the previous answer was stale, and that is worth a line in your notes.

Check your understanding

1. Your virsh list is empty on a host you know is running four guests. What is the first thing you check?

1. A colleague pastes kvm-ok output to prove a host is accelerated. Why is that not enough?

1. Why does this course care so much whether a host emulates or accelerates, if every command works either way?

Summary and next step

• KVM is a kernel module that lends the processor to guests; QEMU provides the rest of the machine, and can

emulate the processor too; virtio is the paravirtual device model; libvirt manages the whole arrangement.

• An unprivileged virsh talks to your own session instance until you tell it otherwise.
• Three tools answer the acceleration question and only one of them actually tries: open /dev/kvm.

Next: lesson 2 takes the management plane apart — which daemons do what, where the definitions and logs live, and how all of it maps onto Proxmox VE, which is the same engine under a different management layer.

References

• libvirt: Deployment and documentation index — https://libvirt.org/docs.html (accessed 2026-09-19)
• libvirt: Connection URIs — https://libvirt.org/uri.html (accessed 2026-09-19)
• QEMU: System emulation and accelerators — https://www.qemu.org/docs/master/system/index.html (accessed 2026-09-19)
• Linux kernel documentation: KVM — https://docs.kernel.org/virt/kvm/index.html (accessed 2026-09-19)
• Ubuntu Server documentation: virtualization with libvirt and QEMU — https://documentation.ubuntu.com/server/how-to/virtualisation/ (accessed 2026-09-19)