Setting up a hypervisor on a brand-new LTS release always comes with a bit of hesitation. You know the fundamentals haven’t changed much, but every release tweaks something — a renamed package, a systemd unit that behaves differently, a kernel module that now loads under a different name. Ubuntu 26.04 LTS, codenamed Resolute Raccoon, is no exception. It ships with Linux kernel 7.0, a substantial jump from the 6.8 kernel that shipped with 24.04, and Canonical has bundled a refreshed Hardware Enablement virtualization stack that will keep receiving updates aligned with future interim releases.

If you’ve installed KVM on Ubuntu before, most of the muscle memory still applies. The package names are the same, libvirt still does the heavy lifting, and virt-manager remains the go-to GUI for anyone who doesn’t want to memorize virsh syntax. But there are a few wrinkles worth knowing about before you dive in — particularly around the new Rust-based system utilities (sudo-rs and rust-coreutils are now default on this release) and the fact that some hardware-specific kernel modules behave slightly differently under kernel 7.0.

This guide walks through a full KVM installation on Ubuntu 26.04 LTS — from verifying hardware virtualization support, to installing the correct package set, configuring libvirt permissions, setting up a network bridge, and creating your first virtual machine with virt-install or virt-manager. Along the way, I’ll flag the things that actually trip people up in production: group membership not taking effect until relogin, bridge interfaces silently failing on cloud-init managed servers, and NUMA-related performance quirks that only show up once you’re running more than two or three guests. Whether you’re building a home lab, a dev/test sandbox, or provisioning a bare-metal node for a small hosting setup, this is the same process I’d run on a client server today.

Why KVM Instead of VirtualBox or VMware Workstation?

KVM (Kernel-based Virtual Machine) isn’t a third-party hypervisor bolted onto Linux — it’s part of the kernel itself, turning your Linux box into a type-1 (bare-metal) hypervisor once the appropriate CPU extensions are enabled. That distinction matters more than it sounds. VirtualBox and VMware Workstation are type-2 hypervisors running as applications on top of your OS, which adds an extra layer of overhead and, frankly, extra points of failure.

For production or semi-production workloads — running isolated test environments, hosting multiple client VMs, or building a small private cloud — KVM combined with libvirt gives you near-native performance with far less resource tax. It’s also what powers most of the infrastructure behind OpenStack, Proxmox VE, and a good chunk of cloud providers’ compute layers. If you’re already comfortable with systemctl, iptables/nftables, and general Linux service management, KVM will feel like a natural extension of your existing toolkit rather than a separate product to learn.

Prerequisites Before You Start

Before touching a single package, confirm the basics. Skipping this step is the single most common reason people open a support ticket saying “KVM won’t install” when the real issue is that virtualization extensions are disabled in firmware.

• CPU with hardware virtualization support (Intel VT-x or AMD-V), enabled in BIOS/UEFI
• Ubuntu 26.04 LTS installed as either Server or Desktop edition, fully updated
• At least 4 GB RAM for basic lab use (8 GB+ recommended if running multiple guests)
• A user account with sudo privileges
• SSH access if you’re working on a headless server (most production boxes are)

Checking CPU Virtualization Support

Run this first, always:

egrep -c '(vmx|svm)' /proc/cpuinfo

A result greater than zero means your CPU supports hardware virtualization — vmx for Intel, svm for AMD. If you get a 0, either virtualization is disabled in your BIOS/UEFI settings (the most likely culprit) or you’re running inside a nested VM that hasn’t been configured to pass through virtualization extensions.

For a more thorough check, install cpu-checker and run kvm-ok, which actually verifies whether KVM acceleration can be used, not just whether the CPU flags are present:

sudo apt update
sudo apt install -y cpu-checker
kvm-ok

You should see: “INFO: /dev/kvm exists” followed by “KVM acceleration can be used”. If instead you get a message about the module not loading, double-check that Secure Boot isn’t blocking the KVM kernel modules — this has bitten more than one admin on freshly imaged Dell and Lenovo servers.

Step-by-Step: Installing KVM on Ubuntu 26.04 LTS

Step 1: Update Your System

Never skip this, especially on a release as fresh as 26.04. Kernel 7.0 is new enough that early point releases are still shaking out driver quirks.

sudo apt update && sudo apt upgrade -y

If the system prompts for a reboot after a kernel update, do it now before proceeding — installing KVM packages against a stale running kernel can cause module mismatch errors later.

Step 2: Install the KVM Package Stack

This is the core install. The package names haven’t changed from 24.04, which is a relief:

sudo apt install -y qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager

Here’s what each package actually does, because understanding this saves you debugging time later:

• qemu-kvm — the actual hypervisor emulation layer that KVM hooks into
• libvirt-daemon-system — the libvirtd service, which manages VM lifecycle, storage pools, and networking
• libvirt-clients — command-line tools like virsh for managing VMs without a GUI
• bridge-utils — legacy bridging tools, still useful for manual bridge troubleshooting
• virtinst — provides virt-install, essential for scripted or unattended VM provisioning
• virt-manager — the GTK-based GUI, handy if you’re on Desktop edition or forwarding X11/VNC

On Ubuntu 26.04’s Wayland-only desktop, virt-manager still runs fine, but if you’re doing this over SSH with X forwarding from an older client, note that X11 has been officially dropped as a session type on the desktop side — you’ll want to rely on VNC or SPICE for remote graphical console access instead.

Step 3: Enable and Start libvirtd

sudo systemctl enable --now libvirtd
sudo systemctl status libvirtd

You want to see “active (running)” in the status output. If libvirtd fails to start, check journalctl -u libvirtd -e immediately — nine times out of ten it’s an AppArmor profile conflict or a leftover socket file from a previous install attempt.

Step 4: Add Your User to the Required Groups

This step is where almost everyone gets tripped up, so pay attention here. Adding yourself to the kvm and libvirt groups grants permission to manage VMs without needing sudo for every single virsh command.

sudo usermod -aG kvm,libvirt $USER

Now here’s the part people forget: group membership changes don’t apply to your current shell session. You either need to log out and back in, or run:

newgrp libvirt

If you skip this and immediately try to run virt-manager or virsh list –all, you’ll get a permission denied error even though the usermod command “succeeded.” It’s not broken — it just hasn’t taken effect yet.

Step 5: Verify the Default Network

Libvirt creates a default NAT network automatically. Confirm it’s active:

sudo virsh net-list --all

You should see a default network marked as active and set to autostart. If it’s inactive, bring it up manually:

sudo virsh net-start default
sudo virsh net-autostart default

This default NAT setup is fine for lab environments and isolated testing, but for anything resembling production — where guests need to be reachable directly on your LAN — you’ll want a bridged network instead. More on that below.

Setting Up a Network Bridge for Production Use

NAT networking works, but it hides your VMs behind the host’s IP, which is a dealbreaker if you’re running services that need direct LAN or public IP access — a mail server, a web app behind its own firewall rules, or anything that needs to be reachable without port forwarding gymnastics.

On modern Ubuntu, Netplan handles this. Edit (or create) a config file under /etc/netplan/:

sudo nano /etc/netplan/01-kvm-bridge.yaml

network:
  version: 2
  renderer: networkd
  ethernets:
    enp3s0:
      dhcp4: false
      dhcp6: false
  bridges:
    br0:
      interfaces: [enp3s0]
      dhcp4: false
      addresses: [192.168.1.50/24]
      routes:
        - to: default
          via: 192.168.1.1
      nameservers:
        addresses: [1.1.1.1, 8.8.8.8]

Lock down file permissions before applying — Netplan is picky about this and will refuse to apply configs with overly permissive access:

sudo chmod 600 /etc/netplan/*.yaml
sudo netplan apply

Swap enp3s0 for your actual interface name (check with ip a) and adjust the IP scheme to match your network. One real-world gotcha: if you’re doing this over SSH, applying a bad bridge config can drop your connection instantly. Always test bridge changes with console/IPMI access available, or use netplan try, which auto-reverts if you don’t confirm within a timeout window.

Creating Your First Virtual Machine

Option A: Using virt-manager (GUI)

Launch it:

sudo virt-manager

From there: File then New Virtual Machine then choose “Local install media” then browse to your ISO then assign vCPUs and RAM then allocate disk space (20 GB+ recommended for a general-purpose Linux guest) then finish. The wizard is intuitive enough that most admins can complete it without documentation, but keep an eye on the network selection dropdown — pick your bridge (br0) instead of the default NAT if you configured one.

Option B: Using virt-install (Scripted, Headless-Friendly)

This is the method I actually prefer for servers, because it’s repeatable and scriptable:

wget -P /var/lib/libvirt/images/ https://releases.ubuntu.com/26.04/ubuntu-26.04-live-server-amd64.iso

sudo virt-install \
  --name web01-vm \
  --ram 4096 \
  --vcpus 2 \
  --disk path=/var/lib/libvirt/images/web01-vm.qcow2,size=25,format=qcow2 \
  --os-variant ubuntu24.04 \
  --network bridge=br0,model=virtio \
  --graphics vnc,listen=0.0.0.0 \
  --cdrom /var/lib/libvirt/images/ubuntu-26.04-live-server-amd64.iso \
  --noautoconsole

A note on –os-variant: libvirt’s OS database may not have a specific ubuntu26.04 entry yet on freshly released systems. Run osinfo-query os to check available variants — falling back to ubuntu24.04 or generic won’t break anything functionally, it just affects some default device optimizations.

Use –network bridge=br0,model=virtio rather than the default e1000 emulated NIC — virtio drivers give you significantly better throughput since they’re paravirtualized rather than fully emulated.

Performance Tuning Considerations

Getting KVM installed is the easy part. Getting it to perform well under real workloads is where experience actually matters.

CPU allocation: Don’t overcommit vCPUs blindly. A common mistake is assigning more total vCPUs across guests than physical cores available, which causes CPU contention and unpredictable latency spikes under load. For latency-sensitive workloads, pin vCPUs to specific physical cores using virsh vcpupin and consider isolating a NUMA node if your server has multiple sockets.

Memory: Enable hugepages for memory-intensive guests — it reduces TLB miss overhead significantly on workloads like databases running inside VMs. Also consider disabling KSM (Kernel Samepage Merging) if you’re running memory-sensitive workloads, since the deduplication scanning itself consumes CPU cycles that might not be worth it depending on your guest density.

Disk I/O: Always use the virtio-scsi or virtio-blk driver for guest disks rather than IDE emulation. Pair this with qcow2 images stored on fast local NVMe or SSD-backed storage pools — spinning disks under heavy multi-VM I/O will bottleneck fast. If you’re running write-heavy workloads, consider cache=none with io=native in your disk XML to bypass unnecessary host-side caching layers.

Network: Stick with virtio NICs, and if you’re pushing serious throughput between guests or to the host, look into enabling multiqueue virtio-net to spread packet processing across multiple vCPUs instead of bottlenecking on a single queue.

Security Hardening for KVM Hosts

A hypervisor is a single point of compromise for every guest running on it, so treat host security with proportional seriousness.

• Keep AppArmor enabled for libvirt — it’s on by default on Ubuntu and confines what each QEMU process can access on the host filesystem
• Restrict libvirtd’s TCP listener; unless you specifically need remote management, keep it bound to local Unix sockets only
• Apply firewall rules (nftables or ufw) that explicitly control which ports guests can expose externally, especially if you’re using bridged networking
• Rotate and audit SSH keys used for any remote virsh management connections
• Keep the host kernel patched — kernel 7.0 on 26.04 is new, and virtualization-related CVEs tend to get disclosed and patched quickly given how widely KVM is deployed

Given that Ubuntu 26.04 defaults to sudo-rs and Rust-based coreutils, also double check any custom automation scripts that parse command output from tools like ls or ps for edge-case formatting differences — most scripts won’t break, but it’s worth a quick regression test before pushing changes to a fleet of hosts.

Troubleshooting Common KVM Installation Issues

• “KVM acceleration can NOT be used” from kvm-ok:

Almost always a BIOS/UEFI setting. Reboot into firmware setup and enable Intel VT-x/VT-d or AMD-V/AMD-Vi. On some Dell and HP servers, this setting is buried under a “Processor” or “Advanced CPU Configuration” submenu rather than a top-level virtualization toggle.

• libvirtd fails to start after install:

Check journalctl -xeu libvirtd. A frequent cause is a stale /var/run/libvirt/libvirt-sock file from a previous crashed session — remove it and restart the service. Another common cause is AppArmor denying access to a storage path outside the default /var/lib/libvirt/images directory; check /var/log/syslog for apparmor=”DENIED” entries.

• Permission denied when running virsh commands:

You forgot to relog after the usermod group change. Run newgrp libvirt for the current session or simply log out and back in.

• Bridge network doesn’t come up after netplan apply:

Double-check that the underlying physical interface name is correct — interface names can shift between kernel versions, especially after a major jump like the 6.8-to-7.0 kernel upgrade in this release. Run ip link to confirm current naming before troubleshooting further.

• VM has no internet access despite bridge appearing “up”:

Verify IP forwarding is enabled on the host: sysctl net.ipv4.ip_forward should return 1. If not, add net.ipv4.ip_forward=1 to /etc/sysctl.conf and reload with sudo sysctl -p.

• Slow disk performance inside guests:

Confirm you’re using virtio disk drivers, not IDE. Check with virsh dumpxml <vm-name> | grep disk — if you see bus=’ide’, that’s your bottleneck.