The Backup Post Ate My ISO Machine — Part 13 of Building a Resilient Home Server Series

A bit late in the day but here part 13. The Windows dev machine died, so the ISO builder moved to the server — QEMU/KVM VM with virtiofs so builds land directly on the network share. The usual parade of things went wrong along the way.

https://blog.ppb1701.com/iso-builder-vm-on-nixos2-part-13-of-building-a-resilient-home-server-series

#NixOS #homelab #selfhosted #libvirt #QEMU #virtiofs #Samba #linux #homeserver #blog

I'm looking for some advice. I have a #Proxmox install with a ZFS pool mounted at `/tank` and my #Nextcloud data at `/tank/nextcloud`

I currently have a non-Docker version of Nextcloud running in an LXC container but it has... issues.

I'm thinking of running the Docker AIO image but I every time I try to pass through the `/tank/nextcloud` directory to a VM via #VirtioFS, it ends up causing the host kernel to panic.

Is there another way to do this?

Unhappy with #DockerDesktop on #macOS? Give #Colima a try!

It's a free and open #container runtime for macOS. It now supports the macOS #virtualization framework, #virtiofs for fast volume mounts and forwarding #inotify events for hot/live reloading. It can even provide a #containerd, #kubernetes or #incus runtime.

https://github.com/abiosoft/colima

(I would've preferred #podman, as that's what I'm mostly using in production, but it still doesn't support forwarding inotify events on macOS)

I've switched from #9pfs to #virtiofs mount for a VM I run under my #proxmox host at home and did a few #fio benchmarks.

9pfs (before):

seq read (1M, 1 thread) - 1950 MiB/s
rand read (4K, 4 threads) - 213 MiB/s
seq write (1M, 1 thread) - 468 MiB/s
rand write (4K, 4 threads) - 80 MiB/s

virtiofs (after):

seq read (1M, 1 thread) - 5258 MiB/s
rand read (4K, 4 threads) - 291 MiB/s
seq write (1M, 1 thread) - 1074 MiB/s
rand write (4K, 4 threads) - 84 MiB/s

2.7x sequential read, 2.3x sequential write, 1.3x random read, and 1.05x random write.

Pretty good improvements!

Especially that this is for my media (movies/tv) mount where mostly sequential I/O is typically performed.

Note the underlying hardware is Samsung QVO SATA SSD, which is rather slow SSD, and likely a bottleneck in those random read/write tests. I expect there would be much bigger differences on a fast NVMe drive.

Been testing out the #virtiofs support now baked into #proxmoxVE. It works, had to do some #selinux adjustments on #fedora to allow my #podman containers to use the mountpoint. Added this policy

```
(allow container_t unlabeled_t ( dir ( read write )))
```

In raw speed it is definitely not a winner - #nfs is easily double the speed. But on this particular VM I don't need the speed - it is nice that this is all self-contained now, and I can actually remove NFS altogether.

#proxmox

Linux und eine WindowsVM teilen sich ein Laufwerk

VirtioFS ist eine Technologie, die es ermöglicht, Dateisysteme zwischen dem Host-Betriebssystem und Gast-Betriebssystemen in einer virtuellen Umgebung effizient zu teilen. Es bietet eine hohe Leistung und niedrige Latenzzeiten, da es speziell für den Einsatz in Virtualisierungsumgebungen optimiert ist.

#kvm #qemu #virtiofs

https://dirkwouters.de/linux-und-eine-windowsvm-teilen-sich-ein-laufwerk/

I've been using #virtiofs to access the host filesystem in my #guix #kvm #libvirt #VMs - it's very nice. I have it mount the directory automatically in my guix-system definition:

(file-system
(mount-point "/home/la/workspace")
(device "workspace")
(type "virtiofs")

Guix also supports the 9p filesystem and others.