When trying to mount a host path into a running VM, first I see the volume is not available, the mount point directory is created but there’s nothing mounted on it.
Then if I restart the VM, I see virtiofsd being briefly spawned at startup on the host but disappears right away. There’s no log mentionning virtiofs in incus monitor.
This time, the volume was mounted in the VM, but any attempt to access the content freezes (for example ls or df). I guess the syscalls stay stuck because there’s no virtiofsd on the host responding.
I see incus is using virtiofsd and qemu provided by zabbly’s repo. I have been using these versions also with libvirt, and it works fine. So the virtiofsd / qemu combination itself seems fine.
root@delmak:~# cat /var/log/incus/stgraber-dev_d13/disk.etc.log
[2025-03-24T16:19:39Z INFO virtiofsd] Waiting for vhost-user socket connection...
[2025-03-24T16:19:39Z INFO virtiofsd] Client connected, servicing requests
[2025-03-24T16:19:50Z ERROR virtiofsd] Waiting for daemon failed: HandleRequest(InvalidParam)
virtiofsd exits as soon as the VM attempts to perform the mount.
So that’s why it dies instantly during hotplug and takes longer on start.
The only host side flag we’re passing is the cache. I tried all 3 values we support and it fails in all 3.
QEMU logs this:
qemu-system-aarch64: Failed to write msg. Wrote -1 instead of 52.
qemu-system-aarch64: vhost_set_vring_addr failed: Invalid argument (22)
qemu-system-aarch64: Failed to set msg fds.
qemu-system-aarch64: vhost VQ 0 ring restore failed: -22: Invalid argument (22)
qemu-system-aarch64: Error starting vhost: 22
qemu-system-aarch64: Failed to set msg fds.
qemu-system-aarch64: vhost_set_vring_call failed 22
qemu-system-aarch64: Failed to set msg fds.
qemu-system-aarch64: vhost_set_vring_call failed 22
qemu-system-aarch64: Unexpected end-of-file before all data were read
Looking online, I only came up with a similar report where IOMMU was involved.
We don’t enable IOMMU by default, so that’s not likely to be the issue.
It may be worth reporting this to the virtiofsd folks to see if there’s some other debugging steps to better understand what’s going on.
Our VM definitions on x86 and aarch64 are as similar as we can make them, so I’m not sure why we’re not seeing this on x86.
virtiofsd also changed a lot, especially for Debian 12.
There was a C version which I think is still what’s in Debian 12 proper, then this got rewritten completely in Rust and that’s what’s now included in the Zabbly package and what Debian 13 will be shipping with.
Yes I saw that major change in virtiofsd, but since it works when used by libvirt (when I point it to the incus binaries for qemu and virtiofsd), I assume there’s no major issue there.
I tried copying over the version in C from debian into /opt/incus/bin, but it didn’t help, it actually got worst, now incus itself get stuck when starting the VM.