Libvirt Setup Fedora 44



In Try Fedora 44 we installed f44-min, a minimal Fedora 44 VM. Now it becomes a hypervisor of its own: it gets libvirt, a user who can manage virtual machines without typing a password, and a separate disk where all the VM images will live. Later in the series, the machines that make up the lab run inside it.
This is a refresh of the 2020 libvirt setup. Networking used to be part of it. It now gets a post of its own, because the lab needs more than the NAT network from 2020.
Access
Log in to f44-min and install the virtualization group. Add the tools that manage SELinux file labels too: the storage section needs them, and the minimal install doesn't have them.
$ ssh -i id_ed25519 -p 2222 fedora@localhost
$ sudo dnf install @virtualization policycoreutils-python-utils
Libvirt on Fedora 44 is a set of small daemons, one per job, each started on demand through a systemd socket. The install enables those sockets but doesn't start them:
$ systemctl is-active virtqemud.socket virtnetworkd.socket virtstoraged.socket
inactive
inactive
inactive
$ sudo systemctl start virtqemud.socket virtnetworkd.socket virtstoraged.socket
The system connection, qemu:///system, is the one that can manage networks and storage for the whole machine. A normal user isn't allowed to use it yet. polkit asks for a password, and the fedora user doesn't have one:
$ virsh -c qemu:///system list --all
==== AUTHENTICATING FOR org.libvirt.unix.manage ====
System policy prevents management of local virtualized systems
Authenticating as: fedora
Password:
A polkit rule lets members of the wheel group in without a password, the same trust sudo already gives them. polkit picks up new rules by itself, with no restart:
$ sudo tee /etc/polkit-1/rules.d/49-nopasswd_global.rules <<RULE
polkit.addRule(function(action, subject) {
if (subject.isInGroup("wheel")) {
return polkit.Result.YES;
}
});
RULE
$ virsh -c qemu:///system list --all
Id Name State
--------------------
Fedora also ships a narrower rule for the libvirt group. Adding a user to that group gives them libvirt and nothing else, which is the better choice on a machine shared with other people.
Storage
f44-min's own 7 GB disk holds only the operating system. VM images get a disk of their own, 40 GB, created on your machine and attached to the running VM:
$ qemu-img create -f qcow2 f44-min.vdb.x86_64.qcow2 40G
$ virsh attach-disk f44-min $PWD/f44-min.vdb.x86_64.qcow2 vdb \
--driver qemu --subdriver qcow2 --targetbus virtio --persistent
--persistent attaches the disk now and keeps it in the VM's definition, so it's still there after a restart. Inside f44-min it shows up straight away as vdb.
Format it, and mount it at /storage. The fstab entry uses the filesystem's label rather than the device name, so it keeps working if the disks are ever renumbered:
$ sudo mkfs.ext4 -L storage /dev/vdb
$ sudo mkdir -p /storage
$ echo "LABEL=storage /storage ext4 defaults 0 0" | sudo tee -a /etc/fstab
$ sudo systemctl daemon-reload
$ sudo mount /storage
VM images go in /storage/images. SELinux only lets the hypervisor open files labelled as VM images, and a new directory isn't. semanage records the label for the directory and everything that will ever be created in it, and restorecon applies it now:
$ sudo mkdir -p /storage/images
$ sudo chown fedora:fedora /storage/images
$ sudo semanage fcontext -a -t virt_image_t "/storage/images(/.*)?"
$ sudo restorecon -Rv /storage/images
Finally, a storage pool tells libvirt about the directory, so that disk images can be created and listed through it:
$ cat > storage.xml <<XML
<pool type="dir">
<name>images</name>
<target>
<path>/storage/images</path>
</target>
</pool>
XML
$ virsh -c qemu:///system pool-define storage.xml
$ virsh -c qemu:///system pool-autostart images
$ virsh -c qemu:///system pool-start images
$ virsh -c qemu:///system pool-list
Name State Autostart
------------------------------
images active yes
f44-min is now a hypervisor with somewhere to keep its disks. Next, a base image: a sealed Fedora install that every lab machine starts from.