Can not mount share using the new virtiofs feature

[llonchj]

Describe the issue

Windows 11 Preview guest can not mount share using the new virtiofs feature.

Configuration

• UTM Version: 4.0.1
• macOS Version: 12.5.1
• Mac Chip (Intel, M1, ...): M1

Upload VM
config.plist config.plist.zip

[osy]

Did you install the right drivers?

[llonchj]

Good point! Can you please point me to the Windows11 arm drivers? Thanks

[osy]

https://virtio-fs.gitlab.io/howto-windows.html

[ehntoo]

I've been very confused trying to use the virtiofs sharing feature with a windows 10 guest on x86_64 macOS. These are the flags that get added to my QEMU command line:

-fsdev
local,id=virtfs0,path=PATHHERE,security_model=mapped-xattr
-device
virtio-9p-pci,fsdev=virtfs0,mount_tag=share

These flags seem to correspond to a 9p-based virtfs share (https://wiki.qemu.org/Documentation/9psetup), rather than the vhost-user-fs-pci device I'd expect from virtiofs (https://virtio-fs.gitlab.io/howto-qemu.html). I have not found any guest drivers for windows that would enable mounting a virtfs share, only those that will mount virtiofs. AIUI, VirtioFS effectively tunnels fuse directly over a socket, and requires an additional host-side support daemon that I don't believe has yet been ported for use in qemu on macOS. Apple has provided support for VirtioFS in Virtualization.framework, but I don't think that's available from userspace.

The Windows drivers linked in https://virtio-fs.gitlab.io/howto-windows.html look for a PCI device 1AF4:105A (https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viofs/pci/viofs.inf#L44) rather than the 1AF4:1009 that seems to be provided by the virtio-9p-pci device.

Should the mentions of VirtioFS in the release note features and app be replaced with VirtFS, or have I missed something?

[sbates130272]

I will chime in and say I see the same thing here. The QEMU invocation from UTM 4.0.5 would suggest we are creating a virtio-9p-pci device and not a virtiofs device? Is this the intention?

[ColCh]

So finally after bashing into the wall for some time, I need to dump my knowledge for other searchers, may be somebody will save their time.

I use macos on macbook pro with m3 max, and windows guest arm64

The Windows drivers linked in https://virtio-fs.gitlab.io/howto-windows.html look for a PCI device 1AF4:105A (https://github.com/virtio-win/kvm-guest-drivers-windows/blob/master/viofs/pci/viofs.inf#L44) rather than the 1AF4:1009 that seems to be provided by the virtio-9p-pci device.

That's correct, indeed, we can confirm this by this list from https://access.redhat.com/solutions/7047921

docs/specs/pci-ids.txt:1af4 vendor ID
docs/specs/pci-ids.txt:1af4:1000  network device (legacy)
docs/specs/pci-ids.txt:1af4:1001  block device (legacy)
docs/specs/pci-ids.txt:1af4:1002  balloon device (legacy)
docs/specs/pci-ids.txt:1af4:1003  console device (legacy)
docs/specs/pci-ids.txt:1af4:1004  SCSI host bus adapter device (legacy)
docs/specs/pci-ids.txt:1af4:1005  entropy generator device (legacy)
docs/specs/pci-ids.txt:1af4:1009  9p filesystem device (legacy)
docs/specs/pci-ids.txt:1af4:1041  network device (modern)
docs/specs/pci-ids.txt:1af4:1042  block device (modern)
docs/specs/pci-ids.txt:1af4:1043  console device (modern)
docs/specs/pci-ids.txt:1af4:1044  entropy generator device (modern)
docs/specs/pci-ids.txt:1af4:1045  balloon device (modern)
docs/specs/pci-ids.txt:1af4:1048  SCSI host bus adapter device (modern)
docs/specs/pci-ids.txt:1af4:1049  9p filesystem device (modern)
docs/specs/pci-ids.txt:1af4:1050  virtio gpu device (modern)
docs/specs/pci-ids.txt:1af4:1052  virtio input device (modern)
docs/specs/pci-ids.txt:1af4:10f0  Available for experimental usage without registration.  Must get
docs/specs/pci-ids.txt:1af4:10ff  upstream merge or shipping a distro/product) to avoid conflicts.
docs/specs/pci-ids.txt:1af4:1100  Used as PCI Subsystem ID for existing hardware devices emulated
docs/specs/pci-ids.txt:1af4:1110  ivshmem device (shared memory, docs/specs/ivshmem-spec.txt)

So this device "VirtFS" from UTM app is actually this one.

1af4:1009  9p filesystem device (legacy)

NOTE: it's NOT virtio device, it's 9p

Speaking shortly,

There are no virtio-9p drivers for Windows. Please use virtio-fs. Those are not same devices.

Ref: virtio-win/kvm-guest-drivers-windows#682 (comment)

/thread. Just kidding :)

Looks like there is a 9p driver virtio-win/kvm-guest-drivers-windows#126 (comment)

How to mount 9p share from windows. TLDR: share your dir over network on macos host, and mount it on windows using Mile.Cirno

Looks like we need to tune qemu flags a bit, because this is how it looks like by default:

-fsdev local,id=virtfs0,path=/Users/colch/Downloads,security_model=mapped-xattr
-device virtio-9p-pci,fsdev=virtfs0,mount_tag=share -name "Windows  ntlite"
-uuid 9AA6812A-233A-4FE8-96E0-B4AC0A390ADA

we need to share 9p over TCP and port forward that port to VM

I did it like this

-fsdev local,id=virtfs0,path=/Users/colch/Downloads,security_model=mapped
-device virtio-9p-pci,fsdev=virtfs0,mount_tag=share
-chardev socket,id=char0,host=0.0.0.0,port=12345,server,nowait
-device e1000,netdev=net1
-netdev user,id=net1,hostfwd=tcp::54321-:12345

(You could add custom QEMU args in UTM app)

Then, from VM, checked that port of 9p is accessible (TcpTestSucceeded : True)

PS C:\Users\colchWin11VM> Test-NetConnection -ComputerName 192.168.64.1 -Port 54321


ComputerName     : 192.168.64.1
RemoteAddress    : 192.168.64.1
RemotePort       : 54321
InterfaceAlias   : Ethernet
SourceAddress    : 192.168.64.7
TcpTestSucceeded : True

And, mount it:

PS C:\Users\colchWin11VM> cd C:\Users\colchWin11VM\Downloads\Mile.Cirno_1.0.501.0_Binaries\ARM64
PS C:\Users\colchWin11VM\Downloads\Mile.Cirno_1.0.501.0_Binaries\ARM64> .\Mile.Cirno Mount TCP 192.168.64.1 54321 share C:\MyMount
>>
Mile.Cirno 1.0 (Build 501)
(c) Kenji Mouri. All rights reserved.

PS C:\Users\colchWin11VM\Downloads\Mile.Cirno_1.0.501.0_Binaries\ARM64> cd C:\MyMount
cd : Cannot find path 'C:\MyMount' because it does not exist.
At line:1 char:1
+ cd C:\MyMount
+ ~~~~~~~~~~~~~
    + CategoryInfo          : ObjectNotFound: (C:\MyMount:String) [Set-Location], ItemNotFoundException
    + FullyQualifiedErrorId : PathNotFound,Microsoft.PowerShell.Commands.SetLocationCommand

As you could see, no errors reported, nothing, no mount :(

Reported that to Mile.Cirno repo, here: ProjectMile/Mile.Cirno#6 (comment)

---

Additional info: Redhat itself suggests sharing via NFS or Virtio https://docs.redhat.com/en/documentation/red_hat_enterprise_linux/9/html/configuring_and_managing_virtualization/sharing-files-between-the-host-and-its-virtual-machines_configuring-and-managing-virtualization#sharing-files-between-the-host-and-its-virtual-machines_configuring-and-managing-virtualization