Oh, one other thing. You mention you have trouble with Windows guests using the virtiofs shares as well. Several months ago I was having a lot of issues with my Windows guest; the shares were disappearing for no apparent reason. I think it was running out of file descriptors when scanning through all the files on the large virtiofs shares. That was when I started using virtiofsd-rust on the host - it had some options that the base virtiofsd did not. This is the option that fixed my issue with the Windows guest:
--inode-file-handles=<inode-file-handles>When to use file handles to reference inodes instead of
O_PATHfile descriptors (never, prefer, mandatory).
- never: Never use file handles, always use
O_PATHfile descriptors.- prefer: Attempt to generate file handles, but fall back to
O_PATHfile descriptors where the underlying filesystem does not support file handles orCAP_DAC_READ_SEARCHis not available. Useful when there are various different filesystems under the shared directory and some of them do not support file handles.- mandatory: Always use file handles. It will fail if the underlying filesystem does not support file handles or
CAP_DAC_READ_SEARCHis not available.Using file handles reduces the number of file descriptors virtiofsd keeps open, which is not only helpful with resources, but may also be important in cases where virtiofsd should only have file descriptors open for files that are open in the guest, e.g. to get around bad interactions with NFS’s silly renaming (see NFS FAQ, Section D2: “What is a “silly rename”?”).
Default: never.
And my script:
virtiofsd --socket-path /tmp/virtiofsd-win10-T --shared-dir /mnt/trafalgar --cache never --inode-file-handles=mandatory