Virtualisation and hypervisors
Type 1 and type 2 hypervisors, hardware virtualisation extensions, paravirtualised drivers, live migration, and why a guest rarely performs exactly like bare metal.
Two kinds and where they run
| Type | Runs | Examples | Typical use |
|---|---|---|---|
| Type 1 (bare metal) | Directly on hardware | KVM, Xen, ESXi, Hyper-V | Data centres and cloud providers |
| Type 2 (hosted) | As an application | VirtualBox, VMware Workstation | Developer machines |
| Hybrid | Kernel module plus user-space tool | KVM with QEMU | Linux hosts |
| Container runtime | Shares the host kernel | containerd, Docker | Process isolation without a guest kernel |
| MicroVM | Minimal guest kernel | Firecracker, gVisor | Fast, lighter isolation boundaries |
- KVM is a kernel module that uses the CPU's virtualisation extensions; QEMU provides the device model and the machine definition.
- A Type 1 hypervisor needs no host operating system between it and the hardware.
- Containers are not virtual machines: there is no guest kernel, so startup is milliseconds rather than seconds.
- A microVM brings back a guest kernel but strips it down, trading a little isolation strength for much lower overhead.
Hardware support and paravirtualisation
# is hardware virtualisation available?
egrep -c '(vmx|svm)' /proc/cpuinfo
lsmod | grep kvm
virsh list --all
virsh dominfo myvm | head
# inside a guest: is it virtualised, and which hypervisor?
systemd-detect-virt
dmidecode -s system-product-name 2>/dev/null- Intel VT-x and AMD-V provide the CPU instructions that make trapping and running guest code efficient.
- Nested paging (EPT or NPT) lets the CPU translate guest addresses without a software page table walk per access.
- A paravirtualised driver is written to cooperate with the hypervisor, avoiding the cost of emulating a real device.
- Virtio devices are the standard paravirtualised network, block and console interfaces on Linux guests.
- Full emulation of a legacy device exists for compatibility and is significantly slower than virtio.
| Device path | Approach | Relative performance | Compatibility |
|---|---|---|---|
| Emulated e1000 | Full device emulation | Slow | Works with any guest |
| Virtio-net | Paravirtualised | Near native | Requires guest drivers |
| Emulated IDE disk | Full emulation | Slow | Legacy guests |
| Virtio-blk | Paravirtualised | Near native | Modern guests |
| SR-IOV passthrough | Hardware function per guest | Native | Requires hardware and a guest driver |
| GPU passthrough | Dedicated device | Native | One guest per device |
Live migration and guest performance
- Copy the guest's memory to the destination while it is still running.
- Track pages written during the transfer so they can be sent again.
- Briefly pause the guest, copy the last dirty pages, transfer device state, and resume on the destination.
- Update the network so traffic follows the guest, typically by re-announcing an address or moving a virtual interface.
# a live migration with libvirt
virsh migrate --live --persistent --undefinesource myvm \
qemu+ssh://dest-host/system
# resource contention shows up as steal time inside the guest
top -b -n1 | head -3
# %Cpu(s): ... 0.0 st
# st is time the guest wanted to run but the host did not schedule it| Symptom in the guest | Likely cause |
|---|---|
| High steal time | Host CPU oversubscribed |
| Clock drift | Guest without a time sync or TSC handling |
| Slow disk with low guest load | Host storage saturated by another guest |
| Occasional long pauses | Live migration, or memory overcommit and ballooning |
| Network throughput below the link rate | Emulated device rather than virtio |
💡
Correct clocks are the most commonly missed guest configuration. Install a time service, be explicit about the clock source, and verify after every migration — a drifting guest clock breaks TLS validation and distributed consensus in ways that are hard to trace.
FAQ
Container or virtual machine?
A container for density and fast startup when the workload is trusted. A virtual machine when the workload is untrusted, needs a different kernel, or needs a stronger boundary.
Why is my guest slower than the same workload on bare metal?
Usually the device path, the host being oversubscribed, or memory overcommit. Check steal time and confirm virtio drivers are in use before blaming the workload.
Related
Containers, namespaces and cgroups Booting, init systems and services
Last refreshed 2026-09-18.