VirtFS / 9p support for Windows
ildar opened this issue ยท 98 comments
#60 notes that "Gal is working on it".
I didn't find his repo. So let's track progress here!
@hammerg , @YanVugenfirer invited ;)
@ildar unfortunate "working on it" is a bit exaggerated. I made a working prototype using dokan few years ago. However I failed to take it to the next step and implement it as a file system driver. I'll get back to it but it will take time.
Any progress on this project? I'm using ftp sharing to guest and have not so good performance against virtualbox. I'm curious how can the 9p increase the performance. Can someone here post some info about it? Thanks.
No updates yet. It is still in the queue.
Is it possible to get the code for your proof of concept? I would like to try and help if possible...
I'm looking forward to using Virtfs on Windows guest OS๏ผ
@Warrentheo maybe you want to look into [this piece of code, I foiund](https://github.com/mifritscher/qemu/tree/556be221a307381ab6406c24f3ad76cd1dac1878/hw/9pfs in a qemu fork) by @mifritscher. @hammerg what do you think about it?
Attention: I tried to make 9p running on a Windows host, NOT on a Windows guest!
The biggest obstacle is that the variants of open(root-directory,directory in this root-directory) is needed for security. The "normal" Win32 API can't do this, but the ntdll API can luckily archive this. Is a bit of pain because of conversions and the functions need to be called by getProcAddress, but it is doable. I'll search for my test code this evening. It can open a directory, but has e.g. stack corruption problems.
In my understanding a proper 9p fs solution for Windows should come in two pieces - some sort of bus driver (virtio device) and a network file system driver (so-called "monolithic redirector" driver, which with some modifications might be used for network fs over vsock as well). I might be able to start working on some sort of POC a bit later, if Gal doesn't mind of course.
Hey great response times, folks!
Maybe Dokany could help with the file system driver part?
ReactOS (Windows XP clone) could be interested in that as well. They added support for NFS and VirtualBox shared folders, both using the redirector infrastructure. Because ReactOS is open source this could ease the development - and at least the redirection code part of the NFS driver could be reused.
I'm interested in this implementation.
Any update yet?
Unfortunately, the project is on hold.
Ok, thank you for your work. Do you know when the project could be started on again?
No... I guess the current option is an external contribution. We can try and guide implementation.
Ok, hopefully someone can pick this up in the future, thanks anyways.
To my understanding, Windows 10 can act as a 9P client to access files of its Windows Subsystem for Linux (WSL). So there will probably already be a 9P implementation in the Windows Kernel.
Might there be some way to re-use that to use virtfs inside of a Windows guest?
More information: https://devblogs.microsoft.com/commandline/whats-new-for-wsl-in-windows-10-version-1903/
Just an update to this, with WSL2 (Announced yesterday, May 6th), the Linux kernel compatibility layer has been replaced by the real Linux kernel! Read up more about it here: https://devblogs.microsoft.com/commandline/announcing-wsl-2/
now exists virtio-fs, very better than virtio-9g
@alphaonex86 virtio-fs looks very cool. But since it's based on FUSE it probably won't work on Windows either, right?
virtio-fs seems a bit bleeding edge - its not even made it into any linux distro's yet, so windows is surely years away
good feature to track here.
Virtio-fs appears to have been added: e864b9b
This is likely due to it's inclusion into the 5.4 kernel.
Virtio-fs appears to have been added: e864b9b
This is likely due to it's inclusion into the 5.4 kernel.
Do you know if the future Virtio-fs driver work with -virtfs device?
hmm the driver still isn't in the latest ISO?
I had an open question about this in a seperate issue. Closed it as duplicate to this one.
When will viofs be included as a signed driver in the virtio-win iso?
I had an open question about this in a seperate issue. Closed it as duplicate to this one.
When will viofs be included as a signed driver in the virtio-win iso?
It should be included in the next release in about 3 months.
Sounds like there are virtio-FS Windows drivers available now, right?๐ฅฐ
Sounds like there are virtio-FS Windows drivers available now, right?smiling_face_with_three_hearts
where did you find it? it's not included in the virtio-win iso (https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/) yet
0.1.185-2 was released today; https://fedorapeople.org/groups/virt/virtio-win/direct-downloads/archive-virtio/virtio-win-0.1.185-2/ - unfortunately without virtio-fs. I guess this is just a patch release for the 0.1.185.
virtio-fs is not a part of build 185. It was initially included in build 186. I will try to build a new RPM and make it public soon, hopefully by end of the week.
As I see, virtio-win-0.1.187-1 now contains 9p drivers in /viofs/ directory. Unfortunately, there is no support for win7 at the moment. Are there any plans to include w7 drivers?
Thanks!
also interested in win7 support. but happy that finally released for win10. now i can create fake local drives with a linux filesytem. great for spoofing apps! (with upcomming -m switch, not yet included with current release)
@hammerg Isn't the Win7 support can be solved by just adding the build configuration?
I'm not getting the driver to work properly. I have added the virtfs in qemu like this:
-virtfs local,path=/mnt/extra/,mount_tag=D,security_model=mapped \
And it makes a new device show up in windows; "PCI Device". When trying to install (even force install) the driver on this device, it still lists as "PCI Device" and not loading.
I will gladly help in troubleshooting this, but I'm not sure what to do next. Any advice?
EDIT: Found some events in event viewer that might help:
Device PCI\VEN_1AF4&DEV_1009&SUBSYS_00091AF4&REV_00\3&2411e6fe&0&18 was not migrated due to partial or ambiguous match.
Last Device Instance Id: PCI\VEN_1AF4&DEV_1052&SUBSYS_11001AF4&REV_01\3&2411e6fe&0&18
Class Guid: {745a17a0-74d3-11d0-b6fe-00a0c90f57da}
Location Path: PCIROOT(0)#PCI(0300)
Migration Rank: 0xF000FFFFFB010123
Present: false
Status: 0xC0000719
understanding, Windows 10 can act as a 9P client to access files of its Windows Subsystem for Linux (WSL). So there will probably already be a 9P implementation in the Windows Kernel.
Might there be some way to re-use that to use virtfs inside of a Windows
Just a little bit confused. If latest Win10 already supports 9P, does that mean we do not need to manually install the 9P driver? I just think Microsoft can do it better because they know Windows the best and can do more in kernel.
Does anybody have a idea how to make the virtiofs.exe run automatically in background after Windows boot. A behavior like the standard network drives? Right now i have to open an extra CMD window and keep it open.
Does anybody have a idea how to make the virtiofs.exe run automatically in background after Windows boot. A behavior like the standard network drives? Right now i have to open an extra CMD window and keep it open.
@DocMAX Maybe you can use TaskScheduler? Remember to check "Run whether user is logged on or not".
virtio-latest from Fedora's downloads now includes these under the viofs file. (0.1.187+)
Using device manager, install them to the currently driverless storage device, and hopefully it will just install and thusly be identified as "Virtio FS Device"
Once installed, you'll need to run the virtiofs.exe with the device to be able to see the device as a network drive. I would recommend moving the whole folder for your architecture(e.g. viofs/w10/amd64) to some comfortably static location in your W10 VM. I put mine in C:\Program Files\viofs\
You'll need to install WinFSP for this if you don't already have it. Once installed, it may complain about still not being able to see 'winfsp-x64.dll'. As a work around, you can go find it in your install directory (C:\Program Files (x86)\WinFSP\bin) to get the DLL, and copy the needed DLL into the same folder as your virtiofs.exe
Once this is all done, you'll be able to launch virtiofs.exe and have a network drive. To get virtiofs.exe to run as a service with the system, you can use this command in an Administrator Command Prompt to create a custom service:
sc create viofs binpath="(your binary location)\virtiofs.exe" type=own start=auto DisplayName="VirtioFS Driver"
This will add a Windows service that you can start and stop to mount the drive under the name of 'viofs', and you can set it to automatically start with your system. (Command included will start 'auto', change to 'demand' for manual start/stop from services list if you'd rather)
Now either restart, or start the service from your Services list manually after adding it. You should now be setup with a network drive with the mount_tag
I have stress tested this driver and i must say it's very unstable. I constantly get "qemu-system-x86_64: Failed to read from slave." on the command line. When this happens, only a reboot can bring back the drive in Windows. Please have a look!
Edit: I saw that virtiofsd crashes with "Bad system call"
I just click the virtio-win-gt-x64.msi to install the driver. Am I wrong?
I am afraid I do not install the driver properly. When I start the virtiofs.exe, I get "The service VirtIO-FS has failed to start (Status=c0000008).". And in the device manager, it still shows as PCI device not "Virtio FS Device".
@bingzhangdai what is the hardware-id of your device?
It should look like this:
If you are using libvirt the xml spec should look similar to this (driver type="virtiofs" is important):
<filesystem type="mount" accessmode="passthrough">
<driver type="virtiofs"/>
<source dir="/virtiofs"/>
<target dir="virtiofs"/>
<address type="pci" domain="0x0000" bus="0x0f" slot="0x00" function="0x0"/>
</filesystem>If you're struggling with the driver installer, you can try to point Windows at it manually.
Find the device in device manager, and right click it.
Choose 'Update driver', and in the window that appears, choose 'Browse my computer for driver software'
Then point it to the folder where you extracted the driver on your VM for it: e.g. 'viofs/win10/amd64', and hit next. It should auto detect the driver match, and install it to the device
I use PVE and I manually added the following line in the vm config: args: -fsdev local,security_model=mapped,id=fsdev0,path=/root/mnt/sata0 -device virtio-9p-pci,id=fs0,fsdev=fsdev0,mount_tag=sata0 -fsdev local,security_model=mapped,id=fsdev1,path=/root/mnt/sata1 -device virtio-9p-pci,id=fs1,fsdev=fsdev1,mount_tag=sata1 ( I mount two sata drives). The Linux guest works fine but in Win 10, device manager shows,
Sadly, it does not show up as "VirtIO FS Device", If I update the driver by choosing "Browse my computer for driver software", It shows "Windows was unable to install you PCI Device" :(
@bingzhangdai i think you are not using the right device.
You are using the device virtio-9p-pci. But the device for virtiofs is called vhost-user-fs-pci.
The qemu parameters at my host are:
-chardev socket,id=chr-vu-fs0,path=/var/lib/libvirt/qemu/domain-1-win2/fs0-fs.sock -device vhost-user-fs-pci,chardev=chr-vu-fs0,tag=virtiofs,bus=pci.15,addr=0x0
@bingzhangdai Seems that device 'virtio-9p-pci' isn't quite what the driver is expecting to work with? Don't quote me on that though. As a thing to try;
Attempt it with vhost-user-fs-pci as your device, as defined here: https://qemu.readthedocs.io/en/latest/tools/virtiofsd.html
More detailed reference here: https://virtio-fs.gitlab.io/howto-qemu.html
I'm not getting the driver to work properly. I have added the virtfs in qemu like this:
-virtfs local,path=/mnt/extra/,mount_tag=D,security_model=mapped \
And it makes a new device show up in windows; "PCI Device". When trying to install (even force install) the driver on this device, it still lists as "PCI Device" and not loading.
@idarlund Seems like you may have a duplicate issue to our friend just above here. -virtfs flag appears to be a sort of alias to the 9p-pci device rather than the device the driver is expecting vhost-user-fs-pci. If you're still having that issue, may want to try reviewing the above.
Thanks very much! It seems that I am using the wrong device.
I previously followed the doc Documentation/9psetup FailSpy pointed out.
It seems that, 9p is VirtFS and here, the driver is expecting me to use virtio-fs? VirtFS and virtio-fs are different. Is that correct? Linux supports both the two devices but on Windows, the driver could only use virtio-fs? I get confused with the name. orz
It seems that, 9p is VirtFS and here, the driver is expecting me to use virtio-fs? VirtFS and virtio-fs are different. Is that correct? Linux supports both the two devices but on Windows, the driver could only use virtio-fs? I get confused with the name. orz
I hope not, otherwise we're on the completely wrong thread O_O
But I believe Virtio-FS and VirtFS are different names for the same architecture, just there's a divided way of implementing it based on the VM, though the specifics of how/why eludes me. I may of course be completely wrong about this at which point most of what's above is technically off-topic.
Edit: assuming that virtio-fs and virtfs are the same architecture as is said, virtfs is an offshoot from plan 9's protocol, which itself allows for networked filesystems, and virtfs is the project to adapt that into something different tuned for virtualization environments.
And that -virtfs flag in QEMU could be a legacy in the earlier days when virtfs just was closer to plan9 sharing? Though just guesswork at this point.
Post-Edit, my personal verdict: VirtFS is NOT Virtio-FS. But it does seem like for what people wanted 9-plan support for on a VM, this is a seemingly better drop-in replacement for them. But arguably, 9-plan mount support doesn't exist.
But Windows does have its own solutions for that which can be implemented now thanks to improvements in WSL. Whether KVM needs to support as a driver device seems like a different issue, and a less necessary one as Virtio-FS consumes most of its desire.
So I'd argue this is the correct place still to talk about Virtio-FS support as far as virtio-win project is concerned.
I see. It seems that they are just two different implementations by using the same protocol called 9p. Here we are using one of them.
I think the qemu's doc should clarify this. https://qemu.readthedocs.io/en/latest/tools/virtiofsd.html and https://wiki.qemu.org/Documentation/9psetup use different device for 9p and people can easily get confused.
Thanks very much :)
@idarlund Seems like you may have a duplicate issue to our friend just above here. -virtfs flag appears to be a sort of alias to the 9p-pci device rather than the device the driver is expecting vhost-user-fs-pci. If you're still having that issue, may want to try reviewing the above.
yeah, seems like it! will check out the guide!
Great to see Win10 drivers now but i am also supporting requests for Win7. Would be awesome!
I don't seem to be able to write to the file.
I have stress tested this driver and i must say it's very unstable. I constantly get
"qemu-system-x86_64: Failed to read from slave."on the command line. When this happens, only a reboot can bring back the drive in Windows. Please have a look!
Edit: I saw that virtiofsd crashes with "Bad system call"
Can confirm. I actually got it to work once for a brief moment, then after subsequent restarts i always get Failed to read from slave. even though nothing changed in the setup.
This is great! Thanks for implementing it!
It appears that virtiofs.exe uses the UID/GID from the active console session when the process is started, so if it is run as a service with start=auto as in #126 (comment) (which is still very helpful!) it will require elevation to access (e.g. "You do not currently have permission to access this folder" from Explorer).
To work around this, I'm currently running virtiofs.exe from a scheduled task with logon trigger:
$action = New-ScheduledTaskAction -Execute "C:\Path\To\virtiofs.exe"
$trigger = New-ScheduledTaskTrigger -AtLogon
$principal = New-ScheduledTaskPrincipal 'NT AUTHORITY\SYSTEM'
$settings = New-ScheduledTaskSettingsSet -AllowStartIfOnBatteries -ExecutionTimeLimit 0
$task = New-ScheduledTask -Action $action -Principal $principal -Trigger $trigger -Settings $settings
Register-ScheduledTask Virtio-FS -InputObject $taskUnfortunately, I don't think this handles user switching correctly (since the process is not stopped on logout) or concurrent sessions by different users (not sure how this should be supported).
I also noticed that virtiofs.exe can be executed by users not in the Administrators group, who are then able to modify files on the host. Is this the expected behavior, or have I mis-configured permissions somehow?
Attention: I tried to make 9p running on a Windows host, NOT on a Windows guest!
The biggest obstacle is that the variants of open(root-directory,directory in this root-directory) is needed for security. The "normal" Win32 API can't do this, but the ntdll API can luckily archive this. Is a bit of pain because of conversions and the functions need to be called by getProcAddress, but it is doable. I'll search for my test code this evening. It can open a directory, but has e.g. stack corruption problems.
Hi @mifritscher
You have done a remarkable work ;)
I'm very interesting in your work, and hope to support folder share between windows host and linux guest based on it, i noticed that you sent out a series "[Qemu-devel] Make 9pfs buildable for Windows" in 2017 year, but after that, i can't find next version of this series, I'd like to know if you have updated this series or not, and if it is possible, i can help to continue this work until it is been accepted in qemu upstream, looking forward to your reply ;)
Thanks.
Finally tried VirtFS on Win10. Somehow i am not able to copy large files from host to Windows guest. It works perfectly with small files but every larger file fails with an error about permissions. I don't really think it's permissions as i can copy small files into the same directory and i can also copy any file of any size from the guest system itself.
It works perfectly in with Linux guests and it also works perfectly to copy any file of any size from Windows guest to host.
Anyone else had this issue?
So VirtFS only creates a network device instead of a virtual removable drive?
No, the latest version of virtiofsd.exe can create a vistual physical drive, too!
No, the latest version of virtiofsd.exe can create a vistual physical drive, too!
How would I configure that? My current Proxmox KVM uses the following args:
-virtfs local,path=/tank/storage,mount_tag=host0,security_model=passthrough,id=host0
I tried using the virtiofs drivers from the latest ISO but the device won't intialize.
No, the latest version of virtiofsd.exe can create a vistual physical drive, too!
How would I configure that? My current Proxmox KVM uses the following args:
-virtfs local,path=/tank/storage,mount_tag=host0,security_model=passthrough,id=host0
"-virtfs" is the another folder sharing based on 9P protocol. It doesn't have a Windows driver at the moment.
I tried using the virtiofs drivers from the latest ISO but the device won't intialize.
Look at https://virtio-fs.gitlab.io on how to configure QEMU.
ouf, the situation is quite confusing.
Is anyone getting some ambiguous errors on Windows? This is creating a blank text file on the Windows Guest
Is anyone getting some ambiguous errors on Windows? This is creating a blank text file on the Windows Guest
Getting this exact problem myself.
Is anyone getting some ambiguous errors on Windows? This is creating a blank text file on the Windows GuestGetting this exact problem myself.
Can you add some more context? Such as how did you create the shared drive in qemu/libvirt, debug log from qemu, etc.
Anyone tested this with a NFS directory? It has unstable behavior. Deleting files result in ".nfs0000000..." files.
Tried it out on Windows 10 LTSC 1803. Can confirm that there are some problems with larger files. Trying to copy any file with size over 2 megabytes from shared folder to VM disk results in permission errors. Opening those files directly somewhat works, depending on application (several GB archives can be successfully extracted with 7-zip, but opening PNGs in Windows Photo Viewer results in them being cut off from top). Did not reproduce the blank file bug mentioned above, it successfully created.
Tried it out on Windows 10 LTSC 1803. Can confirm that there are some problems with larger files. Trying to copy any file with size over 2 megabytes from shared folder to VM disk results in permission errors. Opening those files directly somewhat works, depending on application (several GB archives can be successfully extracted with 7-zip, but opening PNGs in Windows Photo Viewer results in them being cut off from top). Did not reproduce the blank file bug mentioned above, it successfully created.
There is an issue for large files copy: #527
If you experience different issues, please open a new issue with a description.
Can reproduce the issue if try to test with a NFS directory (rw)
- Try to create a folder on guest side, hit 'File Too Large' error described above.
- Try to delete a file , deleting files result in ".nfs0000000..." files.
pkg:
qemu-kvm-5.2.0-14.module+el8.4.0+10425+ad586fa5.x86_64
kernel-4.18.0-287.el8.dt4.x86_64
seabios-1.13.0-2.module+el8.3.0+7353+9de0a3cc.x86_64
virtio-win-1.9.16-2.el8.iso
@hammerg is it a RFE if share a NFS? Should we file a bug to track this issue?
Can reproduce the issue if try to test with a NFS directory (rw)
- Try to create a folder on guest side, hit 'File Too Large' error described above.
- Try to delete a file , deleting files result in ".nfs0000000..." files.
pkg:
qemu-kvm-5.2.0-14.module+el8.4.0+10425+ad586fa5.x86_64
kernel-4.18.0-287.el8.dt4.x86_64
seabios-1.13.0-2.module+el8.3.0+7353+9de0a3cc.x86_64
virtio-win-1.9.16-2.el8.iso@hammerg is it a RFE if share a NFS? Should we file a bug to track this issue?
This issue is tracked in downstream as well, will update here if there is process.
Please remove the need of WinFSP and create a full virtual volume in Windows.
Hello.
I've virtualized Windows 11 with bhyve on FreeBSD 13R and It seems to me that the virtio-9p and or the virtio-fs driver does not work. I don't see the folder "mnt" mounted on the root folder of Windows 11. Below you can see which parameters I've used :
bhyve -S -c 4 -m 8G -w -H \
-s 0,hostbridge \
-s 1,ahci-cd,/home/marietto/Downloads/virtio/virtio-win-0.1.208.iso \
-s 2,ahci-hd,/mnt/da0p1/Backups/OS/bhyve/Windows/win11.img \
-s 3,fbuf,tcp=0.0.0.0:5900,w=1440,h=900,wait \
-s 8,virtio-net,tap0 \
----> -s 9,virtio-9p,sharename=/mnt \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
vm0
Reading from this tutorial :
https://virtio-fs.gitlab.io/howto-windows.html
I've realized that there could be some kind of problem with the Win-Fsp- Windows File System Proxy and or with the virtio-fs PCI device driver because I'm not able to enable the virtio-fs service with the command used on the tutorial :
C:> sc start VirtioFsSvc
it gives the error : "the dependency service does not exist or it has been marked for the elimination.
I've attached some screenshots to help you to understand what's happening.
https://ibb.co/m5vm1hd
https://ibb.co/Qd6TS5d
https://ibb.co/3018SGd
Hello.
I've virtualized Windows 11 with bhyve on FreeBSD 13R and It seems to me that the virtio-9p and or the virtio-fs driver does not work. I don't see the folder "mnt" mounted on the root folder of Windows 11. Below you can see which parameters I've used :
bhyve -S -c 4 -m 8G -w -H \ -s 0,hostbridge \ -s 1,ahci-cd,/home/marietto/Downloads/virtio/virtio-win-0.1.208.iso \ -s 2,ahci-hd,/mnt/da0p1/Backups/OS/bhyve/Windows/win11.img \ -s 3,fbuf,tcp=0.0.0.0:5900,w=1440,h=900,wait \ -s 8,virtio-net,tap0 \ ----> -s 9,virtio-9p,sharename=/mnt \ -s 30,xhci,tablet \ -s 31,lpc \ -l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \ vm0Reading from this tutorial :
https://virtio-fs.gitlab.io/howto-windows.html
I've realized that there could be some kind of problem with the Win-Fsp- Windows File System Proxy and or with the virtio-fs PCI device driver because I'm not able to enable the virtio-fs service with the command used on the tutorial :
C:> sc start VirtioFsSvc
it gives the error : "the dependency service does not exist or it has been marked for the elimination.
I've attached some screenshots to help you to understand what's happening.
https://ibb.co/m5vm1hd https://ibb.co/Qd6TS5d https://ibb.co/3018SGd
Hi,
If you are using virtiofs,you must install Winfsp first.And you also need to add depend="WinFsp.Launcher/VirtioFsDrv" to the service creation command line.
If you still failed, you could try to start virtiofs.exe without registering virtiofs as a service
such as
cd xxxxxx/VioFS
virtiofs.exe -d -1 -D -
Thanks,
Xiaoling
Hello All,
Please help us understanding you use cases for using virtio-fs, and thus make us virtio-fs support better.
Please participate in the discussion and add your use cases: #726
Thanks a lot,
Yan.
Note there is a recent patch series to support 9P on Windows on the QEMU side,
see https://lore.kernel.org/qemu-devel/20220425142705.2099270-1-bmeng.cn@gmail.com/
@Marietto2008 Just to be clear - those are the patches that are enabling 9p support when QEMU runs on Windows host. This is not enablement of 9p support in Windows guest.
To apply patches, clone qemu repository, save patches from the mailbox, and use "git am" command to apply the patch series.
What happens if I emulate WIndows on Freebsd with bhyve,then I run qemu on Windows and qemu on Freebsd ? can I create a tunnel between the two qemus applying the patches on qemu for Windows and on qemu for FreeBSD ? Those patches can be applied also on the qemu which run on FreeBSD ? It seems to me that there is not need to run KVM in Windows,right ? Because this is the only thing I can't do,since bhyve does not support the nesting of the vms.
I don't understand the scenario. What's the final goal? Is it to get virtio-fs in Windows guest (VM)? I don't think it will help.
The patches are for QEMU when it runs on Windows (Windows acts as a host). So the virtiofsd, that allows the sharing on the host side will work on Windows.
virtio-fs driver is part of the repository.
virtio-9p support is not planned, but if you want to contribute (btw: you can use virtio-fs as an example) - you are welcomed.
I can help only as tester,but it makes no sense if there aren't programmers interested or if it is even not planned. I haven't any programming language competences.
@YanVugenfirer commented 43 minutes ago:
virtio-fs driver is part of the repository.
I guess, exact location of code is this:
https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/viofs
@YanVugenfirer commented 43 minutes ago:
virtio-fs driver is part of the repository.
I guess, exact location of code is this: https://github.com/virtio-win/kvm-guest-drivers-windows/tree/master/viofs
Yes.
@YanVugenfirer As VirtFS/virtio-9p support is not planned to be implemented, could this issue status be changed to closed as "not planned" rather than "completed"?
@ehntoo virtio-fs is implemented.
Virtio-9p is not planned.
Those are two different devices with similar purpose.
Could it be ported to Windowa XP, which is still heavily used?
@YanVugenfirer I understand that virtfs/virtio-9p is not planned, and stated as such in my message. The title of this issue is "VirtFS / 9p support for Windows", and it is currently closed with a status of "completed". It would be helpful who are new to the project (as I was yesterday) if this issue was closed as "not planned" or similar.. :)
I spent a number of hours yesterday trying to figure out why a virtfs share was not mounting after seeing this issue was closed with an "completed" status.
Again. Virtio-fs and virtio-9p are two different two different devices serving the same purpose from user point of view.
Virtio-fs should be mounted. Try following the instructions:
https://github.com/virtio-win/kvm-guest-drivers-windows/wiki/VirtIO-FS:-Shared-file-system
Could it be ported to Windowa XP, which is still heavily used?
Theoretically it probably could. Practically we are not developing new features for OSes older than Window 8.
It WinFsp supports Windows XP, the porting could be relatively simple.
@YanVugenfirer Please take a moment to read my message again. This issue title is for 9p support. 9p support is not planned. Can you change this issue status to "not planned"?
At least in qemu, "Virtfs" was commonly used to refer to virtio-9p support, which is why I was mentioning "VirtFS". The -virtfs flag in qemu sets up a virtio-9p device. https://wiki.qemu.org/Documentation/9psetup I understand very well that it is not the same as virtio-fs, and am not asking for any support or instruction on how to use this project.
Windows 9p support is planned. v2 patch will be sent to QEMU ML soon. Stay tuned.
Hello @lbmeng : what it means ? can we use v2 patch to create a virtio-9p driver for Windows 11 so that I can use virtio-9p in bhyve ? I'm not a bhyve developer,but I know one that can grab that patch and that can implement it inside the bhyve code. He already took some qemu code and has ported it to bhyve. I find very useful to share a folder between windows and freebsd in bhyve,in this way :
bhyve -S -c 4 -m 8G -w -H \
-s 0,hostbridge \
-s 1,ahci-cd,/home/marietto/Downloads/virtio/virtio-win-0.1.208.iso \
-s 2,ahci-hd,/mnt/da0p1/Backups/OS/bhyve/Windows/win11.img \
-s 3,fbuf,tcp=0.0.0.0:5900,w=1440,h=900,wait \
-s 8,virtio-net,tap0 \
----> -s 9,virtio-9p,sharename=/mnt \
-s 30,xhci,tablet \
-s 31,lpc \
-l bootrom,/usr/local/share/uefi-firmware/BHYVE_UEFI.fd \
vm0
@lbmeng if you are referring to a v2 patch of your 9pfs host support patches in https://lists.gnu.org/archive/html/qemu-devel/2022-04/msg04075.html, this github issue is (or was originally) for windows support for mounting 9p in windows guests.
Windows 9p support is planned. v2 patch will be sent to QEMU ML soon. Stay tuned.
I think you are confusing the support of 9p when QEMU is used in Windows host and the Windows guest driver.
But if you are planning Windows guest 9p support, I will gladly review it.
@ehntoo @YanVugenfirer Thanks for helping clarfy the situation. I meant to share some information and do not mean to confuse anyone.
I know this thread was originally requesting 9p on Windows. I think it needs QEMU to support 9p on Windows first, then it's up to the team here to decide whether a Windows guest driver for 9p is planned or not.
Sorry for any confusion made.
@ehntoo @YanVugenfirer Thanks for helping clarfy the situation. I meant to share some information and do not mean to confuse anyone.
I know this thread was originally requesting 9p on Windows. I think it needs QEMU to support 9p on Windows first, then it's up to the team here to decide whether a Windows guest driver for 9p is planned or not.
Sorry for any confusion made.
No problem :)