Try Linux in a VM: KVM and virt-manager for beginners

You want to explore Linux without immediately changing your existing installation. A virtual machine is a useful first step: the guest receives virtual hardware and its own disk file. The host remains the operating system running virt-manager.

On Cthulhu, my NixOS configuration enables libvirt and virt-manager. This article explains the components and a small Linux trial. A VM is useful for learning the desktop, package management and workflows; it only partly tests your laptop's actual Wi-Fi, graphics and battery hardware.

Distinguish KVM, QEMU, libvirt and virt-manager

These names describe different layers of one setup. virt-manager is not another Linux distribution. A virtual disk is a file or managed volume, rather than automatically a partition on your physical drive.

Hardware acceleration needs suitable CPU virtualization enabled in firmware. If the guest is slow, check acceleration before assigning more virtual CPUs. Additional resources are not always the solution.

Check the host requirements

Inspect the KVM device:

ls -l /dev/kvm

Its existence does not confirm all permissions. With libvirt tools installed, this check provides further information:

virt-host-validate qemu

Read the individual results. A warning about an optional feature does not necessarily prevent a simple Linux guest. Missing virtualization support or access to required devices is more fundamental.

My NixOS file enables:

virtualisation.libvirtd.enable = true;
programs.virt-manager.enable = true;

User nebu also belongs to libvirtd and kvm. These lines are excerpts from the existing module, not a complete configuration. Group changes may require a fresh login. Debian and Arch have their own package and service procedures; NixOS expressions are not shell commands for those systems.

Choose an ISO and a separate disk

Download an appropriate image from the distribution's official website, such as a Debian live image. Check its architecture and integrity using that project's instructions. A corresponding amd64 image is the usual choice for the x86_64 host discussed here.

Open virt-manager and create a machine using local installation media. Select the ISO. As an adjustable example, depending on your host and guest, assign two virtual CPUs, four GiB RAM and a new virtual disk capped at 30 GiB. Leave sufficient memory for the host; these values are not guaranteed minimum requirements for every distribution.

Use a new virtual disk for the exercise. Do not pass through a physical /dev/sd… or /dev/nvme… device. Before installation, confirm that the selected storage belongs to the test guest you created.

Install in the guest and test a workflow

Boot the guest from the ISO. A live environment often allows an initial desktop trial without installation. If you install, the guest's storage selection concerns its virtual disk. Read the installation dialog carefully nevertheless.

After installation, detach the ISO from the virtual CD drive or change the boot order. Otherwise, installation media may keep appearing. Restart and check that the guest boots from its own virtual disk.

Keep the first experiment specific: open a terminal, install an uncritical program through the guest's package manager and launch it. Record the process in the Linux Migration Companion. This gives practical answers about your everyday workflow rather than just a brief impression of the wallpaper.

Understand NAT and the default network

libvirt's commonly used default network uses NAT. The guest has a virtual network connection and can usually reach external services. It does not automatically appear as another directly attached LAN computer.

List defined networks on the system connection:

virsh --connect qemu:///system net-list --all

If default exists but is inactive, deliberately start that existing network:

virsh --connect qemu:///system net-start default

If it is absent, inspect your installation's network-management configuration rather than create a bridge blindly. Permission failures often concern the selected libvirt connection or login. qemu:///session and qemu:///system manage different sets of resources.

Cthulhu's firewall trusts virbr0. This project choice is not a universal recommendation: it changes guest access to the host. NAT alone also does not fully isolate a guest from the LAN. Untrusted software needs a deliberately planned network and sharing arrangement.

Understand snapshots, backups and hardware limits

A snapshot can help with experiments, but support depends on the disk format, storage backend and machine state. It does not replace an independently stored backup. Test restoring a snapshot on an unimportant guest before relying on it.

For a straightforward consistent backup, shut the guest down cleanly and preserve its definition and associated disk files or volumes. Copying only an active disk file can produce inconsistent data. Important guest files deserve the same care as host files.

Virtual devices cannot accurately establish physical Wi-Fi, power-management or GPU compatibility. After a successful VM trial, a live USB and real-hardware test remain useful. The migration guide helps plan that sequence.

Diagnose problems and end the test

Shut the guest down through its normal menu. Closing virt-manager does not necessarily stop a running VM. Before removing the test guest, identify its virtual disks and save any files you want to retain.

References

• Checked Cthulhu configuration.
• virt-manager project.
• libvirt network formats and virsh.
• Debian live images.

References checked on 8 October 2026. Resource allocations are an adjustable exercise example.