Has anyone looked at virtiofs for NixOS VMs?

When I get some spare hours I am hoping to look at changing NixOS VMs to boot on virtiofs instead of Plan 9. I think there’s a good chance this will improve boot times which is nice for my usecase (I use the VMs for testing kernel changes so rebooting is basically all I do with them :joy:).

Just thought I’d check first if anyone’s looked into this already or knows if any blockers?

FWIW I guess this will have to be optional since I think (although I need to research this more carefully) there are some functional differences between virtiofs and 9pfs, some users might depend on the 9p behaviour.

The other potential issue I can see is that you have to start a separate daemon on the host instead of QEMU doing everything for you. This might be really annoying, but it might also be totally fine.

1 Like

I’ve done this with libvirt before and it works fine. :grinning:

1 Like

Check out microvm.nix . It is a good way to run VMs on NixOS and supports virtiofs

2 Likes

Oh that seems like a really cool project. The option to use CHV/Firecracker/crosvm also seems like a nice bonus.

I think unfortunately it’s a little too complex for my specific needs though; IIUC it’s coupled with the host system. So it’s really designed for running “real workloads” with good isolation, rather than quick and dirty ephemeral tests.

For my usecase I am quite happy to just spin up virtiofsd on-demand and kill it afterwards, and I don’t need all the nice TAP networking stuff. But more importantly it needs to work on non-NixOS hosts.

Then again, maybe it can be modified for that usecase, I will look into that if I hit a dead end with the default runner script - thanks for the pointer!

1 Like

microvm.nix tries to support your usecase: Running a MicroVM as a package - microvm.nix

When building a package, you get separate scripts to:

  • Start virtiofsd
  • Create tap interfaces
  • Start the VM

All the optional host module does is running these scripts in systemd services in the right order.

1 Like

Yeah, I’ve actually been using microvm.nix for totally unrelated reasons (needed to test a Firecracker workload) and I think it does actually support my usecase after all.

Still, I think it would make sense to get the feature into the main upstream runner if it fits there, and the performance benefit measurable. (Both might turn out not to be the case, I still haven’t had any time to explore this).