Current state of virtiofs under virtual machines

Incus
1

The documentation is a little brief on “path on the host” disk types. I’ve been exploring virtiofs for my Linux virtual machines with limited success this last week.


incus config device add <instance_name> <device_name> disk pool=<pool_name> source=<volume_name> [path=<path_in_instance>]

When I attempt to mount <volume_name> in my virtiofs enabled guest, I get this error message that the tag isn’t found:

mount -t virtiofs test /mnt/disk

58.808901] virtio-fs: tag ‹test> not found mount: /mnt/disk: wrong fs type, bad option, bad super block on test, missing codepage or helper program, or other error.
dmesg(1) may have more information after failed mount system call.

I see virtiofsd in the process list of the host, so I’m at a loss as to what could be going wrong here from a user perspective.

Haven’t gone spelunking in the code yet but any advice appreciated. Thank you!

2

That’s because you normally have the agent take care of the notification and mounting for you and so don’t need to mess with virtiofs yourself:

stgraber@dakara:~$ incus launch images:ubuntu/22.04 v1 --vm
Launching v1
stgraber@dakara:~$ incus config device add v1 home disk source=/home path=/mnt/home
Device home added to v1
stgraber@dakara:~$ incus exec v1 bash
root@v1:~# df -h /mnt/home/
Filesystem      Size  Used Avail Use% Mounted on
incus_home       90G   21G   65G  24% /mnt/home
root@v1:~# ls -lh /mnt/home/
total 4.0K
drwxr-xr-x 2 root root 4.0K Sep  8 23:35 stgraber
root@v1:~#

If you do, as can be seen above, the virtiofs share names are incus_NAME so incus_test in your case.

1 Like
3

Ah, makes perfect sense. Thank you Stéphane, you’re always so quick to respond and helpful!

Follow up question: I haven’t yet used an operating system with agent support (I’m using OpenWrt and flatcar/coreOS currently) –– does the agent also take care of ireg on the host and does incus offer dax support to the guest? Maybe I should just rely on these helpful incus abstractions and focus on getting the agent running properly under my pet distros…

Lastly, I see the invocation on the host as:

/opt/incus/bin/virtiofsd --fd=3 -o source=/var/lib/incus/devices/system/disk.test.mnt-disk

The (possibly dated) virtio docs also specify the -o cache=always flag and parameters.

./virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=always

Do you happen to know if this is beneficial ?

Lastly, as a point of interest–– it looks like you’ll be able to pull the tags from /sys soon: https://lwn.net/Articles/961448/

4

I did some research on that stuff now. dax hasn’t been merged into QEMU, so it’s not something that can be used. There’s similarly no versiontable mention within the current QEMU codebase which makes me think that ireg has similarly not made it upstream yet.

On the cache front, we’re actually going to be switching to cache=never as the default of cache=auto actually causes issues with systems accessing a very large number of files.
cache=always has some reports of potential data loss/corruption happening, so I don’t think it’s something we’d feel very confident in offering at this point.

1 Like
5

Can i somehow touch virtiofsd options ?

I’m facing this issue:

and probably it’s caused by cache ?

Hristo

6

The next daily build of the Zabbly packages will have cache=never passed to the daemon.
If that clears our other tests, I’ll push it to the Zabbly stable packages.

For users of other packages, you could ask your distro maintainer to cherry-pick the change or wait until Incus 0.7.

1 Like