mackid1993

I personally avoid Linux as a desktop OS. I'm more of a Windows guy. Most of my Unraid server besides the storage portion is done in the Windows VM. That's why VirtioFS was so important to me. I prefer to run as much as I can under Windows and leave a few hands off things like Plex and Roon to Docker. Since Unraid manages the storage I have no need for Windows Server, so I just run Windows 11 Pro. Hopefully the virtio-fs team could fix that issue for you.

Have you tried the rust version of Virtiofsd? Edit: See here

No problem, we should have official drivers very soon! If you're interested you can also use my scripts to mount your shares as individual drive letters rather than just one share mounted as Z:.

Thanks!!

@SimonF I was hoping this post I wrote could be highlighted higher up in the thread. I shared some scripts for mounting multiple Unraid shares as drive letters and made everything pretty much copy and paste. I also added instructions for setting it up with Task Scheduler.

I'm just using stock Unraid, no rust. I'm on 6.12.6 with the test driver and it's very stable.

After testing there is still a memory leak, just a different memory leak now. Edit: See discussion here: https://github.com/virtio-win/kvm-guest-drivers-windows/issues/1004 It appears that the test drivers may have indeed fixed the leak after all.

The new VirtoFS Windows driver can be downloaded here. To use it you have to enable driver test mode at an admin command prompt with bcdedit /set testsigning on I also went into certmgr and added viofs.cat to Trusted Root Certification Authorities and Trusted Publishers. If the watermark bothers you, this little tool makes it go away: https://winaero.com/download-universal-watermark-disabler/ It's useful until this fix is released with the newest Virtio drivers per the Virtio-win team. Once the new drivers are released uninstall the watermark removal tool and turn off testsigning: bcdedit /set testsigning off It seems that after further testing the Virto-win team fixed the leak: https://github.com/virtio-win/kvm-guest-drivers-windows/pull/1022 I made a copy of these drivers so if they disappear someone ping me and I can share a new link. @SimonF and @christophocles thank you for all of your help with this!

@christophocles @SimonF The virtio-win team were able to repro this!

Question, once I have a working BigSur VM, what happens if I upgrade to a newer version of macOS from within the VM? Will everything break?

Ah, what I don't like is they are testing with pre-release drivers. If it's fixed in unreleased drivers how would we know without compiling them?

Does anyone know what C:\Program Files (x86)\fio\fio\fio.exe. The guy who couldn't reproduce it ran that. Is that something new they haven't released yet?

@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.