Last weekend I was looking for a new project for my Raspberry Pi. I was looking for ways to set up a KVM on my Pi5 since it has 8GB of RAM, which is beefy enough for additional virtualisation tasks. Once I started Googling how I should start this task, I would look up “KVM on Raspberry Pi”. Most of the search results were for another entirely different KVM.
A Keyboard, Video, and Mouse (KVM) switch is a hardware device that allows a user to control multiple computers or servers using a single set of keyboard, video display, and mouse devices. While the KVM switch is a great technology that allows you to control multiple computers using your existing setup, I currently use Tailscale for accessing my remote Pis via my home laptop. So that wasn’t what I was looking for. Instead, I was interested in seeing whether I could run a Kernel Virtual Machine (KVM) on my Pi5.
Despite sharing the same acronym, a KVM switch and the KVM software operate in entirely different realms of technology: one is a physical hardware device for managing physical computers, while the other is open-source software built into Linux to create and manage virtual machines. The KVM Switch routes peripheral and display signals between different systems with the press of a button or a keyboard shortcut.
What is a KVM VM?
Kernel-based VM is an open source virtualisation technology for Linux. With KVM, Linux can function as a hypervisor that runs multiple, isolated VMs. KVM was announced way back in 2006 and actually merged into the Linux kernel in 2007. Virtualisation, which lets you run an operating OS inside another OS, is possible thanks to hypervisors.
A hypervisor pools computing resources (like processing, memory, and storage) and reallocates them among VMs. The hypervisor can run multiple VMs at once, manage them, and support the creation of new ones. The physical hardware, when used as a hypervisor, is called the host, while the many VMs that use its resources are guests. Hypervisors need OS-level components such as memory management, process scheduling, I/O, device drivers, security management, a network stack, and more to run VMs.
KVM has all these components because it’s part of the Linux kernel. Every VM is implemented as a regular Linux process, scheduled by the standard Linux scheduler, with dedicated virtual hardware like a network card, graphics adapter, CPU, memory, and disks.
Similarities between KVM and KVM
Both technologies fundamentally exist to solve an efficiency problem: enabling a user to manage multiple OSs from a single workstation without buying duplicate input devices or displays. Whether toggling between two physical tower PCs or switching focus between multiple virtual instances, both implementations allow one operator to interact with distinct, isolated computing environments. Furthermore, both solutions preserve system isolation, ensuring that actions taken within one environment do not interfere with or crash the other operating systems running alongside it.
Differences
The key distinction lies in hardware physical routing versus software virtualisation. A KVM switch is a tangible piece of hardware that physically redirects signal cables (HDMI/DisplayPort and USB) so that a single set of peripherals can control multiple physically distinct servers or PCs. It does not alter how the computers operate; it merely changes which machine receives your keypresses and sends video output to your monitor.
In contrast, a Kernel-based VM is a software module integrated directly into the Linux kernel that turns the host OS into a Type-1 hypervisor. Instead of connecting separate physical machines, the kernel-based KVM partitions a single computer's underlying processor, memory, and storage to simulate entirely separate virtual computers (Guest VMs) on the same bare metal.
The question should’ve been KVM or Xen?
And that brings us to a totally different question. KVM and Xen - what are the differences and which one can I run on my Pi5 for virtualisation? While both KVM and Xen are open-source Type-1 hypervisors that deliver high-performance virtualisation, their core designs and operational structures differ significantly.
KVM is built directly into the Linux kernel as a standard kernel module (kvm.ko). Installing KVM turns an existing Linux OS into a hypervisor, granting you immediate access to standard Linux drivers, process schedulers, and existing system management tools without having to modify the host kernel. Conversely, Xen sits below the OS as a microkernel-based layer that boots first, before any OS. It relies on a special, privileged Guest VM known as Dom0 (Domain 0) to handle hardware access, boot management, and admin control over other Guest VMs (DomU).
KVM relies purely on hardware-assisted virtualisation (using processor extensions like Intel VT-x or ARM Virtualisation Extensions) to run unmodified Guest OSs. Xen historically pioneered paravirtualisation (where guest kernels are modified to communicate directly with the hypervisor API for higher efficiency), though it now supports hardware-assisted virtualisation as well. Furthermore, Xen’s strict separation of the hypervisor microkernel from the control domain (Dom0) isolates hardware drivers away from guest VMs, which makes it a popular architecture for high-security environments like Qubes OS.
For almost all Raspberry Pi 5 use cases, KVM is the far more practical and seamless option.
In the case of the Raspberry Pi, you’ll need to verify hardware virtualisation support before doing anything. Check that ARM CPU virtualisation extensions are available. Check that the KVM hypervisor kernel module is present and accessible with the below command:
ls -l /dev/kvm
You should see an output showing crw-rw---- 1 root kvm ... /dev/kvm.
If /dev/kvm exists, hardware acceleration is supported and active.
The Raspberry Pi’s boot process relies on a proprietary EEPROM-based bootloader that loads GPU firmware and kernel binaries directly from an SD card or NVMe storage (often chainloaded through U-Boot for standard Linux environments). Because KVM is integrated into standard ARM64 Linux kernels (like Raspberry Pi OS 64-bit or Ubuntu), it requires no special bootloader tweaks or UEFI emulation layer. You simply install `qemu-kvm` (QEMU) and libvirt, and the Pi instantly acts as a hypervisor using built-in ARM hardware extensions, allowing me to easily spin up VMs using standard Linux tools like virt-manager or cockpit.
You can run the following command to install the hypervisor, daemon services, and CLI management tools like QEMU core binaries. Since I’m running Raspberry Pi OS Desktop with the graphical interface, I also appended virt-manager to the below command:
sudo apt install -y qemu-system-arm qemu-kvm libvirt-daemon-system libvirt-clients bridge-utils virtinst virt-manager
Once the packages are installed, I just need to startup/enable the libvirtd service to ensure the hypervisor daemon starts automatically on boot:
sudo systemctl enable --now libvirtd
Libvirt includes a default NAT network interface (virbr0) for guest VMs. As soon as the default virtual network was configured, I can simply create my first Guest VM on the Pi5 and use an Ubuntu ARM64 ISO image, sourced from the Canonical website. The virt-install looks a little like this:
virt-install \
--name debian-vm \
--memory 2048 \
--vcpus 2 \
--disk size=10,bus=virtio \
--os-variant debian12 \
--cdrom /path/to/debian-arm64.iso \
--network network=default \
--graphics vnc,listen=0.0.0.0
In contrast, setting up Xen on a Pi 5 requires a complex boot architecture. Because Xen acts as a microkernel that must load before any OS, booting it on an SBC (Single Board Computer) generally requires using U-Boot to load the Xen binary alongside device-tree overlays, a customised Dom0 control domain, and a secondary driver domain. While projects like Xen-Troops exist specifically to compile custom Yocto-based Xen images for embedded systems and automotive apps, setting this up for home or homelab experiments involves significant compilation overhead, non-standard driver configs, and manual partition setups. While maybe not suited to Pi5, it’s not impossible on previous versions like the Pi4, as stated on the Linux blog. For edge use-cases you can certainly stick with KVM for a smooth setup unless you specifically need Xen's compartmentalised driver architecture for complex embedded development. If you’d like to read why Edera specifically opted for Xen when building a secure microservice foundation, check out their blog post.