KVM virtual machines with virtio drivers for maximum guest performance

Electronic Components & DIY Kits

Best component selections

📦 Resistors

🔋 Capacitors

📐 Transistors

🌀 Transformers & Inductors

🎛 Integrated Circuits

⚡ Diodes & Zener Diodes

A virtual machine that emulates physical hardware pays a translation tax on every operation, the guest speaking to an invented IDE controller or an emulated network chip, the hypervisor converting each conversation, and the overhead lands on the one resource a busy host never has to spare. Virtio is the escape: a family of paravirtualized devices where the guest knows it is virtualized, speaks a streamlined protocol directly to the host, and drops most of the emulation cost. The difference is not a rounding error, disk and network throughput multiply several times over with virtio, and every current distribution ships the drivers built in. This article builds the complete virtio setup through libvirt: the device models and their tradeoffs, creating machines with the right drivers from the start, converting existing guests, guest-side tuning that completes the picture, the CPU and memory settings that pair with fast devices, and the measurement loop that proves the configuration on real workloads.

The paravirtual principle and what it buys

Emulated devices exist for compatibility, the guest that cannot know it is a guest, and the price is the full round trip: the guest's driver writes to emulated registers, the hypervisor interprets each write, pretends to be the hardware, and answers back. The virtio model cuts the middle layer down to a shared-memory protocol: the guest's virtio driver places requests in a ring buffer, the host's backend consumes them directly, and the data moves through pages rather than through register theater. The host-side backends run inside the kernel through the vhost modules, vhost-net for the network and vhost-scsi for the storage paths, which moves the hot loop out of the userspace hypervisor process entirely.

The numbers make the choice for any workload that matters. Disk I/O on emulated IDE crawls at tens of megabytes per second with high latency, while the same disk on virtio-blk saturates toward the host's own limits. Network through an emulated e1000 tops out around a gigabit with visible CPU cost in the guest, while virtio-net with vhost reaches tens of gigabits on capable hardware with a fraction of the guest CPU. The virtio family covers every device class a machine needs, disk, network, memory management through the balloon, serial console and RNG, so a guest can be fully virtio rather than partially accelerated.

The disk and network models, choices that matter

Two disk backends carry the virtio storage flag, and the choice between them is the first real decision. Virtio-blk is the simple, fast path, a single block device per disk with the lowest overhead, and it is the right default for the system disk and most data volumes. Virtio-scsi is the full-featured sibling, exposing disks through a SCSI controller, and it earns its complexity where the feature list matters: TRIM and discard support for thin provisioning, hot-add of disks without reboots, and a large device count per controller. The libvirt XML names the bus explicitly, and the created VM carries the choice into its definition:

The cache mode in the same block is the second half of the disk story. Cache none with io native bypasses the host page cache for guest data, writes going to the filesystem or device directly, which pairs correctly with the guest's own filesystem cache and avoids the double-caching that wastes memory on workloads the guest already buffers. The writeback mode trades some safety margin for convenience and remains the sensible default for development machines, while the production pattern is cache none on the data disks with the guest's journal doing the integrity work.

The network follows the same declaration pattern, and the model line in the interface definition carries the whole difference:

Virtio-net with the vhost backend is the default on every current libvirt, and the only reason the model line deserves a glance is confirming that a migrated legacy machine was actually converted, because the difference between virtio and e1000 on the same VM is the difference between a machine that feels native and one that feels virtual.

Creating the fast machine from the start

The clean path is virt-install with the right flags, which builds the XML correctly from the first boot:

virt-install --name app01 \ --memory 8192 --vcpus 4 --cpu host-passthrough \ --disk path=/var/lib/libvirt/images/app01.qcow2,bus=virtio,cache=none,format=qcow2 \ --network network=default,model=virtio \ --os-variant debian12 \ --graphics none --console pty,target_type=serial \ --location http://deb.debian.org/debian/dists/bookworm/main/installer-amd64/

Every performance decision is in the command line: bus virtio on the disk, model virtio on the network, and the CPU mode that deserves its own paragraph. Host-passthrough hands the guest the host's exact CPU, feature flags and all, which lets the guest's compiler, crypto library and applications use every instruction the hardware offers, the mode for production VMs on trusted guests. The milder modes, host-model and custom definitions, suit the migration scenarios where CPU compatibility across hosts matters more than peak performance, and the choice is a policy statement about what the fleet optimizes for.

The console line completes the production shape: a serial console on the guest, the same out-of-band habit the bastion and spot-instance articles built, because a fast machine that cannot be reached during a boot failure is a fast machine that still needs a console trip to the datacenter.

Converting an existing machine to virtio

Legacy guests arrive with emulated devices, and the conversion is an edit-and-boot cycle. virsh edit opens the machine's XML, the target bus on each disk changes from ide or sata to virtio, the network model changes to virtio, and the guest reboots into a different device world, which is where the two preparation steps earn their keep. The guest's boot configuration must reference the disk by UUID or label rather than device name, because the renamed device, hda becoming vda, moves the boot path. And the guest's initramfs must include the virtio drivers, automatic on every current Linux, but worth one check on the older systems this conversion usually targets. Windows guests need the virtio-win driver disk attached for the installer, a one-time step that the Red Hat-provided ISO handles with the standard next-next-finish ceremony.

Guest-side tuning that completes the virtio picture

Half the virtio contract lives in the guest, and three settings complete it. The network multi-queue feature spreads the virtio-net traffic across guest CPUs, one queue pair per vCPU up to a sensible ceiling, and the guest enables the queues with ethtool -L eth0 combined 4, after which a saturated network stops being a single-CPU bottleneck inside the guest. The disk scheduler inside the guest switches to none or mq-deadline for virtio disks, because the guest's queue adds latency to a path the host already schedules, and the modern default on current kernels already made this switch for virtio devices.

Memory is the third guest-side lever, and the hugepages pattern is the production option for the latency-sensitive tier: 2-megabyte pages allocated on the host at boot, the VM definition requesting them, and the guest's memory translation dropping from thousands of small-page lookups to a handful of large ones. The measurable win appears in memory-bound workloads and in the tail latencies of database guests, and the cost is the host's memory granularity, so the pattern suits the dedicated database VM rather than every machine on the host.

Measuring, because the difference is provable

The measurement loop is short and worth running on every new host. Disk: fio inside the guest on the virtio disk, the same command the EBS article used, read and write at queue depth, and the numbers to compare against are the host's own bare-metal results, because a well-configured virtio guest sits within a small percentage of them. Network: iperf3 between guest and host, then guest to a second physical machine, and the gap between the two runs measures the virtualization overhead directly. The monitoring side lands in libvirt's own statistics, virsh domblkstat and domifstat printing per-device counters that feed dashboards, and the CPU line in virsh domstats showing the steal percentage, the number that tells a guest whether its virtio speed is real speed or borrowed host headroom.

The checklist closes the article in working order. Create guests with virtio buses from the first install, disk and network both. Cache none with io native on data disks. Host-passthrough CPU on trusted production guests. Serial console on every machine. Multi-queue network on the throughput tier, scheduler none in the guest, hugepages on the database tier. Convert legacy guests by XML edit with the boot-path preparation first, and prove every configuration with fio and iperf rather than assuming the flags took. A KVM host configured this way is the machine that makes the original question of this series, whether virtualization costs performance, answerable with a shrug and a benchmark graph.
## The balloon device and dynamic memory

The virtio-balloon is the memory management member of the family, a small guest-side service that lets the host ask the guest to hand back free pages, and its honest role deserves careful phrasing because it is one of the most misunderstood devices in the stack. The balloon inflates inside the guest, taking pages the guest reports as free, and the host reclaims them for other guests or its own cache. The operational value on a packed host is the insurance policy: a guest that idles at four of its eight gigabytes can quietly return the difference to the pool, and a host running several such guests banks a reserve without any of them ever feeling a squeeze.

The production discipline around the balloon comes from its failure mode, which is inflation at the wrong moment: a guest whose balloon holds two gigabytes when its workload suddenly spikes has effectively lost two gigabytes of RAM until the balloon deflates, and the deflation is not instant. The pattern that avoids the trap is conservative inflation ceilings, the balloon enabled with a floor the guest never dips below, and monitoring that watches the balloon's current size as a first-class metric, because a balloon that grew during the night and never shrank is a guest with less memory than its configuration says. The alternative that many production hosts choose is simply not overcommitting memory, static allocation, no balloon, every guest's memory guaranteed, and the balloon becomes a tool for the consolidation tier rather than the performance tier, which is exactly the niche where it belongs.

CPU pinning and NUMA awareness on big hosts

On the servers large enough to have multiple CPU sockets and memory domains, the last performance layer is topology awareness, and virtio's speed only materializes when the guest's CPUs and its memory share a physical neighborhood. The first half is vCPU pinning, mapping each guest CPU to a specific host core through the XML:

and the second half is the NUMA cell declaration that keeps the guest's memory allocation on the same node as its pinned CPUs, the host's own numactl hardware output serving as the map for both. The measurable payoff appears in the same places the hugepages pattern does, database tiers and memory-bound services, where a cross-socket memory fetch costs three to four times a local one and the scheduler's random placement averages the penalty across every page. The libvirt NUMA auto-alignment, numatune mode strict with a cell set, handles the placement declaratively, and the host's monitoring confirms it through the per-node memory counters rather than through guest-reported performance alone.

A closing frame for the whole virtio story

The virtio family, disk, net, balloon, console and the SCSI tier above them, is the reason KVM guests run at near-native speed on Linux hosts, and the entire configuration surface fits inside one libvirt XML per machine. The host-side half, vhost in the kernel, hugepages on the tier that needs them, topology pinning on the big boxes, composes with the guest-side half, queues and schedulers and the drivers that every current kernel loads by default. The measurement loop, fio, iperf3 and the virsh counters, is the discipline that keeps the whole stack honest, and the guest that measures within a small margin of its host's bare metal is the virtio contract delivered in full.