Running virtual machines on Linux with KVM and QEMU lets you install another operating system without replacing your current desktop or creating a dual boot setup. You can test a distribution, keep a separate development environment, or run Windows software inside a complete Windows installation.
For a desktop setup, the practical combination is KVM, QEMU, libvirt and Virtual Machine Manager, usually called virt-manager. Each handles a different part of the job. This guide covers preparing the host, creating a guest, choosing sensible settings and protecting its data. For other ways to run applications, see our Linux software and development guides.
How KVM, QEMU, libvirt and virt-manager fit together
The host is your physical Linux computer. The guest is the operating system running inside a virtual machine.
KVM provides hardware assisted virtualization through the Linux kernel. QEMU supplies the virtual computer, including its storage controllers, network adapters and other devices. With KVM acceleration, supported guest CPU instructions execute through the processor’s virtualization facilities rather than relying entirely on software emulation. The QEMU system emulation documentation covers this relationship and the available accelerators.
Libvirt manages virtual machine definitions, storage and networking. Virt-manager gives you a graphical interface to that management layer, so you can create machines and adjust hardware without writing a QEMU launch configuration.
These are complementary tools, not four competing virtualization products. Installing virt-manager alone does not guarantee that the host has all the packages, permissions and firmware needed to start a guest.
Architecture also matters. Running an x86 Linux guest on an x86 host is a different task from emulating an Arm computer on that host. QEMU supports both kinds of work, but cross architecture emulation does not gain KVM acceleration simply because KVM is installed.
When a virtual machine is the right choice
Choose a VM when you need a separate operating system, its own kernel, or a disposable machine whose configuration you can replace. Testing an installer, rehearsing a server upgrade and checking software on another distribution are good examples.
A container serves a different purpose. It isolates processes while sharing the host kernel, making it useful for application dependencies and repeatable development environments. If that matches the task, our guide to local development with Docker and Podman covers the more direct route.
A Windows VM is useful when an application needs Windows itself. It also brings an operating system to maintain, storage to allocate and licensing terms to check. If you only need one compatible application, consider running Windows applications with Wine and Bottles before committing to a complete guest.
Do not treat a VM as a perfect replica of physical hardware. Its virtual graphics adapter, network interface and storage controller can behave differently from the devices in a laptop. A distribution working inside a VM does not prove that its Wi-Fi driver or suspend support will work on your actual computer.
Check the host before installing anything
Processor support and firmware settings
On an Intel or AMD desktop, check for hardware virtualization support and make sure it is enabled in the computer’s firmware settings. Common labels include Intel Virtualization Technology, VT-x, AMD-V and SVM. The KVM preparation requirements identify the relevant processor extensions.
Firmware menus vary, so use the computer or motherboard documentation rather than following an unrelated screenshot. Ordinary KVM guests do not require you to configure PCI device passthrough. Leave advanced IOMMU and device assignment work for a separate project.
If your Linux host is already a virtual machine, the outer virtualization platform must expose the facilities needed for nested virtualization. Changing settings inside the inner guest cannot supply a feature that the outer host has withheld.
Memory, storage and realistic expectations
Plan around the work the host and guest will perform together. A guest that feels comfortable while the host is idle may become unpleasant once you open a browser, editor and video call on the host.
For an initial Linux desktop experiment, consider a host with 16 GiB of RAM and allocate 4 GiB to one guest. Treat that as a planning example, not a requirement or performance promise. An 8 GiB host calls for smaller guests and more restraint.
Prefer fast local storage, and reserve room for updates, temporary files and backups. Before buying hardware primarily for virtualization, check the wider considerations in our Linux hardware compatibility guide.
Install the host virtualization stack
Use your distribution’s supported repositories. You need QEMU with KVM support, libvirt and virt-manager, plus firmware packages where the guest requires UEFI. Avoid assembling a desktop installation from unrelated downloads unless you have a reason to maintain that arrangement.
On Ubuntu, the core package names include qemu-kvm and libvirt-daemon-system. The distribution also documents the permissions needed to manage system guests in its libvirt installation and execution mode guide. Install virt-manager as the desktop management interface.
Fedora packages the same underlying tools, although package groups and service arrangements can differ between releases and editions. Its libvirt installation documentation provides the distribution context. Check the instructions for your installed edition rather than assuming every Fedora system uses the same installation method.
On Arch Linux, libvirt and virt-manager are separate parts of the setup. UEFI guests also need suitable firmware; the Arch libvirt documentation covers that dependency and the surrounding configuration.
Host virtualization components belong in the host operating system. Installing an application inside a container does not, by itself, configure the host’s KVM access, virtual networks or management services. Our guide to native packages, Flatpak and Snap explains the differences between application installation methods.
Choose the correct management connection
Virt-manager can work with system connections and per-user session connections. They maintain separate guest inventories. If a machine appears to have vanished after changing connections, check which connection you selected before recreating it.
A system connection is a practical starting point for persistent guests and managed virtual networks. Session connections suit some user-owned workflows but have different networking and file access constraints. Follow your distribution’s authorization method, and sign out and back in if it requires a group membership change.
Treat permission to manage system virtual machines as administrative access. Do not grant it casually or make virtualization sockets writable by everyone to dismiss an authorization error.
Create your first virtual machine in virt-manager
Start with an ordinary installation ISO from the operating system’s official download service. Verify it using the publisher’s checksum or signature instructions. For a first experiment, an installer image is easier to reason about than an unfamiliar preconfigured disk image.
If the guest distribution is still undecided, use our guide to choosing a Linux distribution to narrow the choice. Pick one guest and get it working before building a collection of half-installed machines.
The following workflow follows the controls in the virt-manager guest creation interface. Labels can vary slightly between packaged versions.
- Select the intended connection. Open Virtual Machine Manager and confirm that the local QEMU/KVM connection is available. Resolve connection errors before starting the installation wizard.
- Create a new virtual machine. Choose local installation media and select your downloaded ISO. Review the detected operating system rather than accepting an obviously incorrect match.
- Allocate memory and virtual CPUs. Begin conservatively. You can revisit the allocation after observing the workload.
- Create a new virtual disk. Choose a clear name and an appropriate storage location. Confirm that you are creating guest storage, not assigning a physical host disk.
- Review the configuration. Give the VM a descriptive name, select the intended virtual network and enable “Customize configuration before install” when you need to check firmware or add devices.
For a straightforward Linux guest, retain the operating system profile’s device defaults unless you have a reason to change them. Review the firmware choice before installation. Switching between legacy BIOS and UEFI afterwards can leave the installed guest without a usable boot path.
Start the guest and complete its installer inside the console window. The partitioning screen normally refers to the virtual disk you created, but check its capacity and identity before approving changes. Attaching physical disks is not part of this beginner workflow.
The installation process otherwise resembles installing Linux on a computer. Our Linux installation guide covers the operating system side without requiring you to repeat the host setup.
After installation, eject the installer ISO or adjust the boot order so the guest starts from its virtual disk. Install guest updates, restart it and confirm that it boots independently of the installation media. That is a useful first checkpoint before changing more hardware settings.
Allocate CPU and memory without starving the host
The following allocations are suggested starting points for experiments, not vendor minimums. Check the guest operating system’s requirements and adjust for the applications you intend to run.
| Guest workload | Virtual CPUs | Guest memory | Virtual disk capacity |
|---|---|---|---|
| Light Linux server lab | 2 | 2–4 GiB | 25–40 GiB |
| Linux desktop testing | 2–4 | 4–8 GiB | 40–80 GiB |
| Windows desktop applications | 4 | 8 GiB or more | 100 GiB or more |
A virtual CPU is a scheduling resource, not a permanently reserved physical core. Assigning every available thread to a guest is not automatically faster. The host still needs time to handle storage, display, networking and its own applications.
Leave memory for the host and allow for virtualization overhead. Do not depend on memory ballooning to rescue a badly overcommitted desktop. If both systems spend their time reclaiming memory or swapping, adding another virtual CPU will not fix the problem.
For example, start one Linux desktop guest with two virtual CPUs and 4 GiB of RAM on a 16 GiB host. Run the intended applications, then inspect both systems using the methods in our Linux resource monitoring guide. Change one allocation at a time so the effect remains clear.
CPU models deserve separate attention. Exposing the host CPU can suit a VM that stays on one machine, but migration and portability require more planning. Keep the default initially unless an application needs a feature it does not receive.
Choose virtual storage and leave room for growth
Two common disk formats are qcow2 and raw. Qcow2 supports features such as internal snapshots and backing files. Raw has a simpler layout and can also occupy less than its full virtual capacity when stored as a sparse file on a suitable filesystem. These properties are covered in the QEMU disk image documentation.
For a first desktop VM, qcow2 is a reasonable choice. There is little value in changing formats before you have identified a storage problem or a requirement that calls for something else.
Distinguish virtual capacity from physical space consumed. A guest might see an 80 GiB disk while its image initially occupies much less host storage. That does not reserve the remaining space for it. Other files can consume the host filesystem before the guest reaches its advertised capacity.
Keep disk images in a managed storage pool when possible. This reduces surprises involving permissions, removable drives and storage paths that disappear after reboot.
Increasing a virtual disk’s capacity is also only part of an expansion. The guest’s partition, logical volume or filesystem may need resizing before the operating system can use the additional space. Back up the guest before changing its storage layout.
Prepare Windows guests for firmware and driver requirements
A Windows guest needs more preparation than a typical Linux guest. Windows 11 requirements include at least two virtual processors, 4 GB of memory and 64 GB of storage, with processor and security requirements applying too. Use Microsoft’s Windows 11 requirements rather than treating the suggested allocations above as a compatibility checklist.
For a conventional Windows 11 KVM setup, prepare UEFI firmware, the appropriate Secure Boot configuration and an emulated TPM 2.0 before installation. The host needs the required firmware and TPM emulator packages. Selecting a firmware filename containing “Secure Boot” is not enough if the complete configuration lacks the expected enrolled certificates.
Libvirt supports per-guest emulated TPMs through swtpm and records firmware state separately from the main virtual disk. Its guest hardware configuration documentation also details CPU exposure and the portability risks of host-passthrough mode.
VirtIO storage and network devices need compatible Windows drivers. Have the driver ISO available alongside the Windows installation media. The VirtIO Windows driver project documents its drivers and links to distribution-neutral installation images.
If Windows Setup cannot see a VirtIO disk, use its driver loading option and select the storage driver matching the configured controller, Windows version and architecture. Do not assume an empty disk list means the virtual disk is missing.
After installation, install the remaining device drivers and verify networking before depending on the guest. Avoid switching an existing Windows boot disk to a different controller without preparing the required driver first. Virtualization also does not remove Windows or application licensing obligations.
Install guest integration tools deliberately
The QEMU guest agent runs inside the guest and provides a management channel. Depending on its configuration, it supports operations such as retrieving guest information, setting time and coordinating filesystem freeze operations. The QEMU guest agent documentation lists these capabilities.
Install the guest’s supported agent package and check that the corresponding virtual channel is present. Installing software without its communication channel, or adding a channel without running the agent, leaves the integration incomplete.
Display integration is a separate matter. With a compatible SPICE configuration, the SPICE agent can provide clipboard sharing and automatic resolution changes. The SPICE guest integration manual describes the guest agent and channel requirements. The QEMU guest agent is not a substitute for it.
Enable sharing only where it helps. A shared directory gives the guest access to real host files within the granted permissions. Prefer a dedicated exchange folder over your entire home directory, especially for disposable guests. Our guide to Linux file permissions and ownership covers the access controls involved.
Start with NAT networking
A managed NAT network is a sensible starting point for a guest that needs outbound internet access. It avoids changing the host’s physical network configuration just to download updates.
Libvirt also supports isolated networks and connections through existing host bridges. Its virtual network configuration documentation distinguishes these arrangements. They solve different problems; “bridged” is not simply a faster setting.
NAT generally lets the guest initiate outbound connections through the host. It does not automatically publish guest services to other computers on your LAN. It also does not prevent the guest from contacting reachable host or network services.
A host bridge can make a guest participate more directly in the physical network. That can help when other computers must reach it, but it also changes exposure and requires host network configuration.
An isolated network supports a private lab without normal forwarding to the outside network. Guests can still communicate with the host and other guests on that network. “Isolated” does not mean disconnected from everything.
For a simple two-machine lab, keep both guests on the same intended virtual network and test their communication before changing the host router or firewall. If a service remains unreachable, separate address assignment, routing, name resolution and service access into individual checks.
Maintain appropriate guest firewall rules too. A virtual network does not replace service access controls. Our Linux firewall guide covers the host and guest tools without requiring you to disable protection to test a connection.
Use snapshots for rollback and backups for recovery
A snapshot is useful before a risky update or configuration change. A backup protects against losing the storage that contains the VM. These are different jobs.
Snapshot behaviour depends on the storage format, snapshot method and attached devices. Some operations capture disk changes; others can include running machine state. Check what the tool will capture before relying on a rollback, especially with UEFI firmware, TPM state or external storage involved.
A snapshot stored alongside its original disk is not protection against losing that drive. It is a recovery point in the same failure zone.
For an uncomplicated offline backup, shut down the guest cleanly and preserve its configuration and storage. The Red Hat virtual machine backup procedure identifies the VM’s XML configuration and disk data as parts of recovery.
Inventory any additional state your guest uses, including UEFI variable storage, virtual TPM data and encryption secrets. If a disk depends on backing images, the newest overlay alone is not a complete copy. Keep recovery passwords somewhere other than inside the guest they would recover.
Do not copy a running disk image with a normal file copy operation and assume you have a consistent backup. Use a supported live backup workflow, or shut the guest down first. Databases may require application-aware preparation even when filesystem coordination is available.
Store a backup away from the VM’s working drive and test restoration. Start the restored copy with networking disconnected initially to avoid duplicate machine identities or services. Our Linux desktop backup and recovery guide covers protecting the surrounding host as well.
Improve performance without changing everything at once
Begin with KVM acceleration, suitable VirtIO devices, sufficient memory and healthy host storage. Then measure the workload. Aggressive CPU tuning is a poor first response to a host filesystem that has run out of space.
Graphics needs separate expectations. A virtual display is not direct access to the host’s graphics card. Linux guests can use supported virtual graphics acceleration through technologies such as VirGL, described in the Mesa VirGL documentation, but compatibility depends on the complete host and guest configuration.
Do not enable every graphics option at once. Establish a working display first, then test acceleration against the application you actually need. GPU passthrough is a separate undertaking, not a routine installation step.
For development, keep a clean baseline guest and document the tools added afterwards. Our Linux development workstation guide helps separate useful tooling from changes that belong only in an experiment.
Troubleshoot the failing layer
Virt-manager cannot connect
Check the selected connection, the host management service or socket, and your account’s authorization. A connection failure happens before the guest operating system starts, so reinstalling that operating system is unlikely to help.
Read the host service logs rather than repeatedly changing permissions. Our guide to troubleshooting services with journalctl explains how to narrow log output to the relevant service and time.
The installer ISO or disk is inaccessible
Confirm that the path exists from the virtualization service’s perspective. A file readable by your desktop account may still be inaccessible to the account running QEMU, or blocked by host security policy.
Use a managed storage location and appropriate permissions. Avoid making your home directory writable by everyone or disabling AppArmor or SELinux as a general repair strategy.
The guest has no internet access
Check that its virtual network is active, its adapter is connected and the guest has an address. Then test access by address separately from hostname resolution. Investigate the guest driver if the network device is missing altogether.
Changing NAT to a bridge introduces another variable. Establish why the existing connection fails before replacing it.
The guest returns to the installer or will not boot
Eject the ISO and check boot order. Confirm that the virtual disk is attached and that the firmware still matches the installation. If those checks pass, investigate the guest’s bootloader and filesystems using the principles in our Linux boot recovery guide.
Keep host and guest failures separate. A guest emergency screen does not mean that the host installation needs repair.
Manage remote hosts without exposing the console
Virt-manager can manage a remote libvirt host through SSH, allowing the graphical interface to stay on your workstation. The Ubuntu Virtual Machine Manager guide documents this arrangement.
Prefer that managed connection over exposing an unauthenticated display or management endpoint to the internet. Protect the remote account using the practices in our SSH access security guide, and grant only the access needed.
Remember that storage selection refers to the machine running the guest. An ISO on your workstation is not automatically available to a remote host just because virt-manager can display its file chooser.
For a first setup, keep the design modest: one guest, one virtual disk, a managed NAT network and no physical device passthrough. Confirm booting, updates, clean shutdown and recovery before adding more machines. A predictable VM is more useful than an elaborate configuration whose last working state nobody recorded.