mackid1993

@SimonF @christophocles Seems like they can't reproduce, they also referenced Virtio drivers .242 which don't seem to be released.

Seems like it's a Virtio driver issue. Winfsp closed their report and provided a pretty good explanation. Hopefully the virtio-win team can reproduce and fix this and hopefully in the next driver release we'll finally be able to use VirtioFS.

Thanks for filling this out and explaining the issue so well. Hopefully one of these teams will patch it. I'm betting its Virtio-win's problem as WinFSP is used in a lot of projects and is pretty stable. I use it with Cryptomator with no issue.

@SimonF He is asking for some more info and I'm not really sure how to provide what he is asking for. Maybe @christophocles can assist.

Thanks Simon. I'll go on there and add a comment as well.

@SimonF, this post explains the issue way better than I can. Maybe you can open an issue, I'm guessing with the Virtio win driver team?

So maybe it's a qemu issue or something with Unraid.

I haven't seen one. Not sure if it's the driver or qemu.

There's still a non-paged pool memory leak in Windows. Hopefully new Virtio drivers or qemu 8 will help.

It seems that memorybacking no longer causes lockups in 6.12.5-RC1 however VirtioFS still seems to cause a memory leak under Windows per my testing.

So it's probably not the driver per-se but something on the QEMU end.

That's great, thanks for the info!

Any news about a QEMU bump for 6.13? Does anyone have any insider knowledge as to whether it is happening.

I just tested, there is still a non-paged pool memory leak with the new drivers. Must be QEMU.

Any news about the new Virtio drivers for Windows? Do they happen to resolve any issues with Virtiofs?

OK so you can change your CPU to this emulated one and everything will work but there is a performance hit from it: Here is the XML. You just have to edit the topology for your cores. I did this on 12700k so I gave it 20 cores. I no longer run this due to the performance issues. <cpu mode='custom' match='exact' check='partial'> <model fallback='allow'>Skylake-Client-noTSX-IBRS</model> <topology sockets='1' dies='1' cores='20' threads='1'/> <feature policy='disable' name='hypervisor'/> <feature policy='require' name='vmx'/> <feature policy='disable' name='mpx'/> </cpu>

Thanks @SimonF! Any idea if we'll see it before the end of the year?

No problem. I just want to again caution against Virtiofs in Windows at this time. It's known to cause lockups. We are hoping that when Limetech decides to upgrade QEMU to 7.2 or newer it will be more stable. I just recently set up a VLAN on my server and bound a secondary virtual NIC to it to keep SMB traffic between my VM and Unraid within the server and not dependent on my home network.

Any news when we'll see a bump for qemu? I'm hoping we can really use Virtiofs soon on Windows.

How To: Setup VirtioFS Under Windows and Mount Multiple Unraid shares as individual drive letters. VirtioFS under Windows is now stable as of Unraid 6.12.5 (QEMU 7.2) and Virtio Drivers 0.1.248-1. Ensure you install this driver or later as well as Unraid 6.12.5 or later. Earlier versions of Unraid will cause the VM to lock up and earlier drivers have an issue where any filesystem IO will cause a large non-Paged pool memory leak. Go to Settings -> VM Manager to grab the latest Virtio Windows drivers. Before anything you must install the WinFSP driver. VirtioFS relies on this and will not work without WinFSP installed. I scripted the initial setup here: This disables the VirtioFS service since we won't be using that. It also registers VirtoFS with the WinFSP launcher. Paste into a batch file and run as admin: sc stop VirtioFsSvc ping 127.0.0.1 sc config VirtioFsSvc start=demand ping 127.0.0.1 cmd /c ""C:\Program Files (x86)\WinFsp\bin\fsreg.bat" virtiofs "C:\Program Files\Virtio-Win\VioFS\virtiofs.exe" "-t %%1 -m %%2"" echo Confirm data was properly entered into HKLM\SOFTWARE\WOW6432Node\WinFsp\Services\virtiofs pause This is the mount script I use. This must be run as admin or scheduled with task scheduler. I like to run it on User Login and once per hour just in case the shares unmount for some reason. I have a little bit of extra stuff at the beginning of the script that will force it to run with admin privileges: @echo off :: Check for admin privileges net session >nul 2>&1 if %errorlevel% == 0 ( echo Running with admin privileges ) else ( echo Running without admin privileges echo Attempting to elevate process... PowerShell -Command "Start-Process -Verb RunAs -FilePath '%comspec%' -ArgumentList '/c %~f0'" exit /b ) :: Rest of your batch file starts here REM Modify the Drive Letters such as viofsJ J: as well as the tag (tag1) to match the tags (case senstive) set in Unraid. "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsJ tag1 J: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsl tag2 L: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsM tag3 M: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsS tag4 S: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsT tag5 T: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsU tag6 U: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsV tag7 V: "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" start virtiofs viofsY tag8 Y: For this script modify as follows for your particular situation: viofsJ and J: should correspond with your drive letter. tag1 should match the tag set in the Unraid web UI exactly case sensitive. Modify these values for all mounts needed and add as many as required. Use this script to unmount VirtioFS shares. This does not need to be run as admin. Modify viofsJ et cetera to match the mount script. "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsJ "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsL "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsM "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsS "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsT "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsU "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsV "C:\Program Files (x86)\WinFsp\bin\launchctl-x64.exe" stop virtiofs viofsY For running the mount script I prefer to set up a scheduled task in Task Scheduler as follows: Where C:\Batch\virtiofs.bat is your mount script. This is all sourced from the documentation here.

I think I figured this out. First I created a VLAN it was called br0.2. Unraid was assigned the IP 169.254.246.19. I modified my SMB extras and added: bind interfaces only = yes interfaces = lo br0 br0.2 Then I added a second NIC to my VM and bound it to br0.2. On my Windows VM I mapped my shares using \\169.254.246.19\share. It seems now that the traffic is staying within Unraid! If anyone sees this I'd appreciate any feedback. I hope I got this figured out right.

Pardon my ignorance, I'm hoping someone could guide me in this or point me in the right direction. I'm wondering how to best set up the networking between my Windows VM and Unraid. I'm wondering if there is a way to keep the traffic between my Unraid shares and Windows VM within the Unraid server so bandwidth isn't bottlenecked by my gigabit router. I know that the Virtual NIC Unraid uses is 10 gbit so I was wondering how I can configure things so traffic internal to the Unraid server gets the full 10 gbit throughput. For example if I access a file on one of my Unraid shares mounted over SMB I don't want the rest of my network to be a bottleneck if possible. I'm wondering if there is a way to achieve this with a VLAN, I just don't know how to do it and I'm hoping there is a guide somewhere that can help me achieve this. Thanks!!

FYI this is supposed to be fixed in the new version of QEMU which we are supposed to get in 6.13. It's a memory leak, if you watch taskmgr the non-paged pool will slowly balloon until Windows runs out of memory.

I got around to doing a bit more testing and there definitely is a performance hit from this.

Any word as to when we'll see Qemu 7.2? I'm dying to use this feature in Windows to overcome the SMB bottleneck.