[predictabl3]

Hard to trust this when the conclusion is to use NFS instead of VirtioFS. I don't buy that NFS over network, to a VM is faster than 9p, and certainly isn't faster than VirtioFS. Though "share from the VM" is good advice for NFS, since you can just reboot the guest when some part of NFS inevitably hangs (not-so-distant trauma here, including learning how to force power-off when shutdown is broken by NFS).

And yes, it works with Windows: https://virtio-fs.gitlab.io/howto-windows.html

[exec1]

The point I was trying to make in the article was more about reversing the direction of mounts so that instead of mounting a host directory on the guest you share a directory from the guest and mount it with a client on the host. You can achieve this using whatever – NFS, Samba, etc. This is obviously not a new concept but I find it astonishing that perhaps the majority of articles on the internet always talk about mounting a host directory on the guest which is problematic due to the reasons I covered in my article.

The main advantage of this approach is that your code resides on a native file system. This allows you to take advantage of this performance gain where it matters most, which for me is during runtime (I develop web applications and IO performance is of paramount importance). I care much, much less about performance on the host side.

[menthe]

Sharing VirtioFS "chroots" that live on top of ZFS is golden to simplify backup strategies & reduce bloat.. while still being able to maintain workload and network isolation.

I'm not backing up entire VMs through ZFS snapshots nor VM snapshots, and don't need a ZFS-enables backup target either. I'm merely backing up the relevant files (e.g. compose stack definitions, config files, data files) that are in the chroot, from the VM host, to GDrive, using popular tooling such as duplicacy.

[exec1]

Also, regarding VirtioFS: this is indeed something I have not yet tried. I’m wary of this though because this requires installing additional drivers on Windows and I usually prefer using tools that are already at my disposal (e.g. Samba on Windows).

[flurie]

Perhaps you should title the post "Keep your files inside your VM on a Windows host".

[exec1]

Not Windows specifically. I work on a macOS host so NFS works fine. However, I want to keep my options open for working on a Windows host if necessary and I wanted to keep to the toolset that already exists on the platform. I want to isolate as many responsibilities as possible inside the VM and then use a client on the host to mount the directory. Bonus points if the host already comes with this client out of the box.