The KVM tesuite driver is only known to work on Linux based systems; specifically Debian and Fedora.

Running on BSD may be possible with some work; Windows is a total unknown.

TL;DR?

Sorry this one has no shortcut.

Minimum Requirements

As with any test framework, the more hardware you throw at it the faster it gets. Here’s a suggested bare minimmum:

• 64-bit x86 processor

  Like most of the guests

• Cores? The more the better.

  We’ve no minimum. While we can’t see why a single core m/c wouldn’t work we can’t find one to prove it.

  Just note that we’re talking real cores, not hyper-threads. The testsuite is CPU bound, so the more physical cores cores the better.

• GHz? The more the better.

  While we’ve no recommended minimum, we’ve data suggesting old slow hardware doesn’t have the grunt to get through crypto in a timely manner. This leads to test-fails due to timeouts and retransmits.

• at least 4gb RAM

  That’s a bare minimum as the m/c is otherwise unuseable.

• Harware Virtualization

  Run grep -e vmx -e svm /proc/cpuinfo to see if it enabled.

  To enable it you’ll need to play with the BIOS.

• an SSD

  Although pointing that out in this day and age is probably superfluous.

• Fedora or Debian host

  Both work and are in use. However, since the testing m/c runs Fedora, the Fedora notes tend to be updated frequently.

  As for *BSD and Mac, in theory … Windows is probably a bridge too far.

Check Virtualization is enabled in the BIOS

Virtualization needs to be enabled by the BIOS during boot.

grep -e vmx -e svm /proc/cpuinfo

Add yourself to sudo

Some of the test scrips need to be run as root. The options are as follows.

Option A: scoped sudo

Create a scoped rule file /etc/sudoers.d/libreswan-testing:

# Scoped sudo for libreswan KVM test suite
Cmnd_Alias LIBRESWAN_VIRSH = /usr/bin/virsh *
Cmnd_Alias LIBRESWAN_VIRT  = /usr/bin/virt-install *
Cmnd_Alias LIBRESWAN_QEMU  = /usr/bin/qemu-img *
Cmnd_Alias LIBRESWAN_IP    = /usr/sbin/ip link *
Cmnd_Alias LIBRESWAN_NFS   = /usr/sbin/exportfs *, /usr/bin/systemctl start nfs-server
Cmnd_Alias LIBRESWAN_FW    = /usr/bin/firewall-cmd *
Cmnd_Alias LIBRESWAN_PERMS = /usr/bin/chmod g+w /var/lib/libvirt/qemu

%libvirt ALL=(ALL) NOPASSWD: LIBRESWAN_VIRSH, LIBRESWAN_VIRT, LIBRESWAN_QEMU, LIBRESWAN_IP, LIBRESWAN_NFS, LIBRESWAN_FW, LIBRESWAN_PERMS

Ensure your user is in the libvirt group:

sudo usermod -aG libvirt $(id -u -n)

Alternatively, if you prefer user-specific rather than group-based rules, replace %libvirt with your username ($(id -u -n)).

Option B: unrestricted sudo

This is setup by adding an entry under /etc/sudoers.d/ specifying that your account does not need a password to become root:

echo "$(id -u -n) ALL=(ALL) NOPASSWD: ALL" | sudo dd of=/etc/sudoers.d/$(id -u -n)

Fight SELinux

If you’re lucky (i.e., Debian) you don’t have SELinux, and can skip this step, but if you do …

SELinux blocks some actions that we need. To check the current settings run:

getenforce

The options are:

• leave SELinux enabled

  • add KVM_SELINUX=true to Makefile.inc.local

    The VMs will then be set up to work with SELinux

  • label the source tree

    The source tree on the host is shared with the virtual machines. SELinux considers this a bug unless the tree is labelled with type svirt_image_t.

    sudo dnf install policycoreutils-python-utils
    sudo semanage fcontext -a -t svirt_image_t "$(pwd)"'(/.*)?'
    sudo restorecon -vR /home/build/libreswan
    

• set SELinux to permissive (recommended)

  sudo sed --in-place=.ORIG -e 's/^SELINUX=.*/SELINUX=permissive/' /etc/selinux/config
  sudo setenforce Permissive
  

• disable SELinux

  sudo sed --in-place=.ORIG -e 's/^SELINUX=.*/SELINUX=disabled/' /etc/selinux/config
  sudo reboot
  

There may be other things that SELinux objects to.

Check that the host has enough entropy

As a rough guide run:

while true ; do cat /proc/sys/kernel/random/entropy_avail ; sleep 3 ; done

it should have values in the hundrets if not thousands. If it is in the units or tens then see Entropy matters

Install Dependencies

Why	Fedora	Debian 13
Basics	sudo dnf install -y make git gitk patch xmlto python3-pexpect curl tar	sudo apt-get install -y make git gitk xmlto python3-pexpect curl tar
Virtualization	sudo dnf install -y qemu virt-install libvirt-daemon-kvm libvirt-daemon-qemu	sudo apt install -y virtinst libvirt-clients libvirt-daemon libvirt-daemon-system libvirt-daemon-driver-qemu qemu-system-x86 libosinfo-query?
Build BSD Boot CDs	sudo dnf install -y dvd+rw-tools	sudo apt-get install -y dvd+rw-tools
NFS	sudo dnf install -y nfs-utils	sudo apt-get install -y nfs-kernel-server rpcbind
Broken makefiles	sudo dnf install -y nss-devel # make file invokes pkg-config nss

Enable libvirt

At some point libvirt replaced the monolythic daemon with modula daemons. See https://libvirt.org/daemons.html#switching-to-modular-daemons

Fedora?

Start the “collection of modular daemons that replace functionality previously provided by the monolithic libvirtd daemon”:

for drv in qemu network nodedev nwfilter secret storage interface ; do
   sudo systemctl unmask virt${drv}d.service
   sudo systemctl unmask virt${drv}d{,-ro,-admin}.socket
   sudo systemctl enable virt${drv}d.service
   sudo systemctl enable virt${drv}d{,-ro,-admin}.socket
done

for drv in qemu network nodedev nwfilter secret storage ; do
   sudo systemctl start virt${drv}d{,-ro,-admin}.socket
done

Debian?

Debian (trixi) seems to still have the old daemons. Hence look through https://libvirt.org/daemons.html#switching-to-modular-daemons but where it says to shutdown the monolythic daemons, start/enable them.

Here’s a hint:

$ sudo systemctl start libvirtd
$ sudo systemctl enable libvirtd
Synchronizing state of libvirtd.service with SysV service script with /usr/lib/systemd/systemd-sysv-install.
Executing: /usr/lib/systemd/systemd-sysv-install enable libvirtd

Stop libvirt daemons shutting down

By default the libvirt daemons timeout and shutdown after 120 seconds (surely systemd will restart them!). It turns out this hasn’t worked so well:

• libvirt clients hang because virtnetworkd.service misses when virtnetworkd is dead

systemd doesn’t restart the daemon

• error: Disconnected from qemu:///system due to keepalive timeout

the restart is painfully slow with lots of networks which causes the timeout

• libvirtd deadlocks (fixed)

• virtqemud gets slower and slower

Disabling the timeout and just leaving the daemons running seems to help. Add the following:

echo VIRTNETWORKD_ARGS= | sudo dd of=/etc/sysconfig/virtnetworkd
echo VIRTQEMUD_ARGS=    | sudo dd of=/etc/sysconfig/virtqemud
echo VIRTSTORAGED_ARGS= | sudo dd of=/etc/sysconfig/virtstoraged

The standard libvirt systemd config files read these settings using EnvironmentFile=

Add yourself to the KVM/QEMU group

You need to add yourself to the group that QEMU/KVM uses when writing to /var/lib/libvirt/qemu. On Fedora it is ‘qemu’, and on Debian it is ‘libvirt-qemu’.

sudo usermod -a -G $(stat --format %G /var/lib/libvirt/qemu) $(id -u -n)

and possibly:

sudo usermod -a -G $(stat --format %G /dev/kvm) $(id -u -n)

After this you will will need to re-login (or run sudo su - $(id -u -n).

Make certain that root can access the build

The path to your build needs to be accessible (executable) by root, assuming things are under home:

chmod a+x $HOME

Fix /var/lib/libvirt/qemu

Because our VMs don’t run as qemu, /var/lib/libvirt/qemu needs to be changed using chmod g+w to make it writable for the qemu group. This needs to be repeated if the libvirtd package is updated on the system

sudo chmod g+w /var/lib/libvirt/qemu

Arguably we should run libvirt as a normal user instead.

Validate things

virt-host-validate