Test suite: consider re-introducing filesystem shares, with virtiofs
Due to problems with 9p filesystem shares, on #5571 (closed) we stopped using them: a11c39b6 replaced them with "I plug and mount a USB drive containing […]" steps. It works well.
One caveat, though, is that in 1 occurrence this effectively creates a 1.2 GiB file in /tmp/TailsToaster
:
"I plug and mount a USB drive containing a Tails USB image". On lizard, this translates into allocating 1.2 GiB more RAM to every isotester, because:
# This feature needs the almost biggest snapshot (USB install,
# excluding persistence) and will create yet another disk and
# install Tails on it. This should be the peak of disk usage.
'features/usb_install.feature',
lizard has basically no spare memory at the moment, which blocks some nice features that we'd like our sysadmins to implement. sysadmin#16960 (closed) will solve this, but we're not there yet, and regardless, even on the new CI machine, we'll keep needing these extra 1.2 GiB of RAM per isotester. This is what made me take another look at filesystem shares.
virtio-fs is now a thing: https://blog.vmsplice.net/2020/02/video-for-virtio-fs-shared-file-system.html.
Requirements:
- QEMU 5.0 added support for
virtio-fs
: Once #17842 (closed) is done we can assume QEMU 5.0. - Linux 5.4 in the guest: we're good
- either one of:
- manually run
virtiofsd
and manually pass extra arguments to QEMU via libvirt (to workaround the lack ofvirtio-fs
support in Buster's libvirt): https://virtio-fs.gitlab.io/howto-qemu.html - libvirt 6.2 on the host (in Bullseye)
- manually run
Can we use virtio-fs
for sharing the USB image with the system under test, and save 1.2 GiB of RAM per isotester?