Set up a KVM virtual machine on Fedora

KVM lets a Fedora host run isolated guest operating systems with hardware-accelerated virtualisation. QEMU provides the virtual CPU and devices, while libvirt manages storage, networking, domains and snapshots through a single administration interface.

The host needs a CPU with Intel VT-x or AMD-V, enabled firmware, and a /dev/kvm device. Allocate at least 8 GB of RAM, 40 GB of free storage and multiple CPU cores for a practical workstation, although lighter configurations can run small servers.

This guide creates a Fedora Workstation VM using virtio devices and UEFI. It also identifies the settings that matter when the same virtualisation stack is used for servers, training systems or workloads in Australian data centres.

Check hardware acceleration

Check the processor flags and confirm that the kernel has created the KVM device:

lscpu | grep -E 'Vendor ID|Model name'
grep -E -m1 '(vmx|svm)' /proc/cpuinfo
test -e /dev/kvm && echo 'KVM device ready'

If the grep command returns nothing, virtual CPU extensions may be disabled in the firmware. A missing /dev/kvm device can also mean the host lacks the required module. Many Australian VPS offerings in Sydney and Melbourne support ordinary virtual machines but do not expose nested virtualisation, which KVM requires.

Install the KVM stack

Fedora packages the required components as qemu-kvm, while libvirt supplies the daemon, storage driver and networking service. Install OVMF for UEFI support and the graphical administration tools:

sudo dnf install qemu-kvm libvirt virt-install virt-viewer \
  edk2-ovmf osinfo-fedora
sudo systemctl enable --now libvirtd
sudo usermod -aG libvirt "$USER"

Log out and back in so the new libvirt group membership takes effect. Desktop users can then launch virt-manager --connect qemu:///system. On a headless system, verify access with virsh list --all over an SSH session.

Prepare storage and networking

Libvirt normally creates a disk pool at /var/lib/libvirt/images and a NAT network named default. Inspect both before creating the guest:

sudo virsh pool-list --all
sudo virsh net-list --all
sudo virsh pool-start default
sudo virsh pool-autostart default
sudo virsh net-start default
sudo virsh net-autostart default

Run the start commands only for resources shown as inactive. Copy the installation ISO into the libvirt directory and replace the example filename with the downloaded release:

sudo install -d -m 0755 /var/lib/libvirt/iso
sudo install -m 0644 ~/Downloads/Fedora-Workstation-Live.iso \
  /var/lib/libvirt/iso/

The default NAT network suits administration, development and training. Many Australian broadband and small-office connections use carrier-grade NAT, so a bridged guest will not automatically receive a publicly reachable address. Published services may instead require a controlled host port forward, VPN or reverse proxy.

Create the Fedora guest

Download the Fedora ISO, calculate its SHA-256 checksum and compare it with the checksum published by Fedora. Select the Server edition instead of Workstation if the guest will provide headless services.

sha256sum ~/Downloads/Fedora-Workstation-Live*.iso
FEDORA_OS=$(virt-install --os-variant list |
  awk -F: '/Fedora/ {gsub(/[[:space:]]/, "", $1); print $1; exit}')

The following command creates a two-core VM with 4 GB of memory, a 25 GB qcow2 disk and virtio devices:

sudo virt-install \
  --name fedora-web \
  --memory 4096 \
  --vcpus 2 \
  --disk size=25,format=qcow2,bus=virtio \
  --cdrom /var/lib/libvirt/iso/Fedora-Workstation-Live.iso \
  --os-variant "$FEDORA_OS" \
  --network network=default,model=virtio \
  --graphics spice,listen=127.0.0.1 \
  --video virtio \
  --boot uefi \
  --noautoconsole

Replace the ISO path with its real filename. The durable XML domain definition and transient QEMU process have a useful separation similar to retaining ViewModel state across an Android configuration change: the definition survives a restart while the runtime process can be replaced. Detach the installation ISO after Fedora has finished installing.

Configure and inspect the VM

Complete the Fedora installation, then configure the guest from its own console:

sudo timedatectl set-timezone Australia/Sydney
sudo timedatectl set-hostname fedora-web
sudo dnf upgrade --refresh
sudo systemctl enable --now firewalld

Australia/Sydney observes AEDT during daylight-saving periods, while Australia/Brisbane remains on AEST throughout the year. Also create a non-root administrator and configure the guest firewall for only the services it actually exposes.

Manage lifecycle and autostart behaviour from the Fedora host:

sudo virsh dominfo fedora-web
sudo virsh autostart fedora-web
sudo virsh shutdown fedora-web
sudo virsh start fedora-web

For graphical access, use virt-manager locally or an SSH-tunneled SPICE connection from another computer. Avoid exposing the libvirt management interface directly to an untrusted network.

Protect and back up the setup

Treat the hypervisor and guest as separate security boundaries. SSH keys, firewall rules and intrusion protection belong on the host as well as inside the VM; Fail2ban SSH protection can reduce repeated SSH attacks when its SSH jail is enabled.

sudo dnf install fail2ban
sudo systemctl enable --now fail2ban

Capture the domain definition and identify the disk before maintenance:

sudo virsh dumpxml fedora-web > fedora-web.xml
sudo virsh domblklist fedora-web --details
sudo virsh snapshot-create-as fedora-web pre-upgrade

A snapshot supports short-term rollback but does not replace an off-site disk backup. Australian hosting decisions should account for latency and contractual data-residency needs, particularly when selecting Sydney or Melbourne regions, then keep encrypted backups in an approved jurisdiction.

The dependable sequence is the thing to remember: hardware acceleration, the QEMU and libvirt stack, a reproducible guest definition, separate host and guest security, and tested backups for both configuration and virtual disk data.