KVM, QEMU, and VirtualBox on Linux 7.2

Linux 7.2 was released on 16 August 2026. That is a kernel version, not a distribution called “Linux 7.2”: Ubuntu, Debian, Fedora, RHEL-derived systems, Arch, and others choose their own kernels, package versions, support policies, desktop tools, and backports. Check the running kernel with uname -r and identify the distribution with cat /etc/os-release. A distribution may ship an older-looking kernel with security fixes backported, or may not yet ship 7.2 at all. This article is a September 2026 guide to cautious local virtualization on x86-64 and ARM64 Linux hosts, not a reason to replace a distribution kernel just to match a version number.

The layers: kernel, emulator, API, and desktop

KVM is the Linux kernel virtualization facility. With CPU virtualization extensions enabled, it lets a same-instruction-set guest execute much of its code on the processor. QEMU supplies the machine model: virtual CPUs, storage and network devices, firmware integration, and an emulator. QEMU can use KVM acceleration, but it can also emulate another CPU architecture in software. libvirt is a service and API which defines, starts, networks, and stores VMs through drivers such as QEMU; it is not itself the hypervisor. virt-manager is a graphical client for libvirt. A typical desktop stack is therefore virt-manager → libvirt → QEMU → KVM, with no need to hand-edit XML until the graphical choices are understood.

On an x86-64 host, an x86-64 or x86 guest is normally the KVM case. On an ARM64 host, an ARM64 guest is normally the KVM case. QEMU can emulate, for example, x86 on ARM64 or ARM on x86-64 using an appropriate system emulator, but that is cross-ISA emulation and is usually substantially slower; it is not native execution and KVM cannot accelerate arbitrary guest instructions across ISAs. Choose installation media, firmware, and device drivers for the guest architecture, not the host brand name.

Verify capability before installing a stack

Firmware virtualization is usually named Intel VT-x or AMD SVM on x86-64. Enable only that documented option in UEFI/BIOS, save, and reboot. ARM64 virtualization support is platform- and firmware-dependent; aarch64 KVM also needs kernel support. The following commands only inspect the system:

uname -m
test -e /dev/kvm && echo "/dev/kvm is present" || echo "/dev/kvm is absent"
ls -l /dev/kvm
lscpu | grep -Ei 'Architecture|Virtualization|Hypervisor'

/dev/kvm present is the important first sign. If it is missing, inspect firmware settings, the running kernel/configuration, and the appropriate KVM module rather than repeatedly changing VM settings. On x86, lsmod | grep kvm commonly shows kvm_intel or kvm_amd; on ARM it may show kvm. This is diagnostic, not proof that every guest will boot. A nested VM may expose no usable KVM device unless its outer hypervisor explicitly enables nested virtualization.

Install distribution packages deliberately

Package names change, so search the distribution repository and read the package description before accepting a replacement. The following are conventional starting points, not commands to paste unchanged into a production server. They install software but do not delete disks or alter a physical network:

# Debian/Ubuntu
sudo apt update
sudo apt install qemu-system-x86 qemu-system-arm libvirt-daemon-system \
  libvirt-clients virt-manager ovmf swtpm

# Fedora/RHEL-family
sudo dnf install @virtualization virt-manager edk2-ovmf swtpm

# Arch Linux
sudo pacman -Syu qemu-full libvirt virt-manager edk2-ovmf swtpm

For a host that will never emulate the other ISA, install only the appropriate QEMU system package if the repository splits it. RHEL-family systems can have subscription, repository, and service-management choices that differ by release; consult the vendor virtualization documentation. After installation, confirm the libvirt service/socket state using the distribution’s documented method, then test with the unprivileged query virsh -c qemu:///system list --all. If it reports a connection or authorization error, fix that first rather than running virt-manager as root.

Permissions are part of the security design

System libvirt normally runs QEMU under a restricted service identity and grants selected desktop users access through polkit and/or a group such as libvirt. On some distributions the group is libvirt; on others a desktop session can use polkit without it. Inspect existing groups with getent group libvirt and follow the distribution’s current libvirt guidance. If adding a user to an authorized group is appropriate, log out completely and back in so the new group membership is active. Do not make a VM manager root-owned just to bypass a permission message, and do not broadly relax filesystem permissions on disk-image directories.

Keep images in libvirt-managed storage or a directory readable by the QEMU service domain. Mandatory access controls matter: SELinux on Fedora/RHEL-family systems and AppArmor on Ubuntu can correctly deny access to a random home-directory path. Prefer creating a libvirt storage pool or use the documented labeling/profile procedure, rather than disabling SELinux or AppArmor. Protect the management socket as seriously as root access: a person who can define a system VM may attach storage or network devices with powerful consequences.

Disks, memory, and a first guest

Use virt-manager’s “New Virtual Machine” wizard to select local ISO media, guest architecture, firmware, RAM, vCPU count, storage pool, and networking. Leave meaningful capacity for the host. A small Linux guest may be comfortable with 2–4 GB RAM and two vCPUs; a DOS-era guest can use far less. A host starved of RAM will swap, and a guest given every CPU often makes the desktop or other services worse. Shut down before changing fundamental storage controller or firmware settings, and keep the ISO’s source and checksum with the project notes.

raw images are simple byte-addressable virtual disks. They may occupy their full virtual capacity immediately or be sparse, depending on how they were created and what the host filesystem supports. qcow2 is QEMU’s copy-on-write format: it can be thin-provisioned, support backing files, and support useful snapshots, but its extra features require careful management. Sparse raw and qcow2 images can both grow until the host filesystem runs out of real space. Inspect rather than modify an image with:

qemu-img info /path/to/disk.qcow2

Do not delete a backing file, rename an image behind libvirt’s back, or “clean up” a snapshot file until its chain is understood. For a portable, consistent backup, shut down the guest, then copy/export the image and its domain definition or use a documented libvirt backup workflow. Test restoring a copy. A snapshot is a short-term rollback point, not an independent backup: it remains dependent on base storage and can consume enough space to jeopardize the host. Take a clearly named checkpoint before a driver or application experiment, and retain separate, powered-off backups on other storage.

Networks: start narrow and expand for a reason

Libvirt’s default network is typically a NATed private network (often named default). A guest can make outbound connections through the host, while it is not ordinarily a first-class device on the physical LAN. It is a sensible starting point for a maintained guest needing updates. An isolated libvirt network has no uplink and is well suited to a retro lab, especially alongside a host-only file exchange. A bridge attaches a VM to the LAN as a peer and is appropriate only when that exposure is deliberate; an unpatched legacy guest should not gain a bridge merely because it makes discovery easier.

Use virt-manager to attach one NIC first and inspect the guest’s address. NAT and a host firewall still do not make obsolete guest services safe to publish. Avoid forwarding old SMB, RDP, web, or file-transfer services to the Internet. For multi-VM demonstrations, use an isolated network; for an old operating system that needs no network, disconnect its virtual NIC. The libvirt network XML documentation explains the precise modes and the libvirt wiki has distribution-oriented guidance.

Devices that match the guest

Virtio devices reduce emulation overhead: virtio-blk or virtio SCSI for storage, virtio-net for networking, and virtio ballooning where the guest supports them. Modern Linux guests normally include drivers; many Windows installers need the signed virtio driver ISO supplied by the Fedora virtio-win project. Retain an emulated SATA/IDE disk or e1000-style NIC for an older guest that lacks virtio drivers, then install drivers before switching devices. A performance setting is not worth making an installation unbootable.

UEFI guest firmware comes from packages such as OVMF on x86-64 and AAVMF/EDK2 variants on ARM64; package layouts vary. Use UEFI for a guest that expects it, and legacy BIOS where a vintage x86 OS expects BIOS. Secure Boot requires a correctly signed guest boot chain and distribution key enrollment; it is not a generic “more compatible” setting. A virtual TPM, commonly provided through swtpm, is useful when a guest explicitly requires TPM 2.0. Its state and keys are part of the guest’s recovery material: back them up appropriately and avoid changing or deleting them after an encrypted guest has been installed.

Pass-through and firmware features deserve restraint

USB redirection or host-device passthrough should be limited to a specific device and guest. It can expose removable media, programming hardware, or a security token to code in that guest; detach it before unplugging and never use the only copy of important data. Shared folders and clipboard integration have similar boundary-crossing risk. A dedicated read-only transfer directory is safer than exposing a whole home directory, and files returning from an old guest should be scanned and treated as untrusted.

VFIO PCI passthrough is a specialized project, not a checkbox for a first VM. It generally needs an IOMMU enabled in firmware and kernel, devices in safe IOMMU groups, drivers detached and rebound correctly, and a plan for the host display/GPU. A group is a hardware isolation unit, not an arbitrary list the user may split. Passing through the GPU that supplies the host’s only display can strand the host; changing boot parameters or driver binding can prevent normal boot. Consult the kernel VFIO documentation and the distribution guide, inventory groups before any change, preserve a known-good boot option, and use a spare compatible device. Do not follow a “bypass” guide for GPU-protected software or anti-cheat systems.

Where VirtualBox 7.2 fits on Linux

VirtualBox 7.2 can be useful when an existing appliance, classroom instruction, or guest workflow specifically expects it. On Linux it normally uses its own host kernel modules (including vboxdrv), while KVM uses the kernel’s KVM path. Both may be installed, but they do not make the same VM simultaneously runnable and they can compete for hardware virtualization resources or complicate diagnosis. Shut down one hypervisor’s guests before starting the other; prefer one stack per project where practical. A VirtualBox VM can be exported or its disk converted only after checking controller, firmware, snapshots, guest additions, licences, and target-format compatibility.

External VirtualBox modules must match the running kernel. A kernel update can leave modules unbuilt until the distribution package, DKMS/akmods integration, matching headers, or a vendor update catches up. On Secure Boot systems, an unsigned third-party module may be refused; use the distribution’s documented module-signing and Machine Owner Key enrollment process, or a properly signed distribution package. Do not disable Secure Boot wholesale as a shortcut. Read journalctl -k yourself when troubleshooting module load failures, but preserve the exact error for support rather than guessing.

Host architecture remains decisive. Oracle’s supported host builds and extension capabilities vary by release and distribution. An x86-64 VirtualBox host is the normal setting for x86/x86-64 guests described in its manual; do not infer that an x86 guest runs natively on an ARM64 Linux host. For cross-architecture work use QEMU system emulation deliberately, accepting the performance trade-off, and use KVM only when host and guest ISA and platform support align.

A compact troubleshooting order

  1. Confirm host ISA, running kernel, firmware virtualization, and /dev/kvm.
  2. Confirm libvirt connectivity and user authorization without running the GUI as root.
  3. Verify ISO architecture and checksum, then choose the intended BIOS/UEFI and Secure Boot state.
  4. Use a single NAT adapter and compatible emulated devices first; add virtio after drivers are available.
  5. Check free host storage and qcow2 backing/snapshot relationships before deleting anything.
  6. For VirtualBox module trouble, match its package and headers to the running kernel and resolve Secure Boot signing through documented tooling.

Authoritative references should take precedence over a version-specific blog post: the Linux kernel KVM documentation, QEMU documentation, libvirt documentation, virt-manager project, and Oracle VirtualBox manual. With an isolated network, modest resources, verified media, and tested powered-off backups, a VM becomes a repeatable retro computer rather than an opaque file that only happens to boot today.