johnsanc

FYI GordonJ just released 3.6.0 which should fix several linux-specific issues, especially with DatVault.

Nope looks like an unresolved issue with qemu and memoryBacking. All we can do is wait I guess. I should add the issues above were also when I was trying to use VirtioFS.

The issue is precisely this: https://gitlab.com/qemu-project/qemu/-/issues/1270 And it has not been corrected. Until there is an update to that issue, I'd say this entire feature should be avoided completely for most people.

I have mentioned this several times before, but the lockups most people are having that peg all CPU cores is directly related to the presence of the memory backing config: <memoryBacking> <source type='memfd'/> <access mode='shared'/> </memoryBacking> Please try to reproduce with JUST this config in place and nothing related to virtioFS.

I mentioned this before, but for me it locks up just with the memory backing config and nothing else related to virtioFS. I don’t think the lockups are related to virtioFS at all. Focus should be directed elsewhere.

Has there been any progress on resolving the lockup issues due to memory backing? This feature is great but completely unreliable for many until that is resolved.

Wow this is fantastic to see someone made a docker container for RomVault. You may want to join the RomVault discord as well for issues with Linux or any other general questions about app usage. Although RV was not specifically created for Linux, many users do use it in various Linux VMs.

I have a SMB issue that keeps coming up. Basically I am compressing a file which is streaming out a temp file over the SMB share writing directly to the array. Sometimes I get an error in my log.smbd file that says. smb2_sendfile_send_data: sendfile failed for file XXXXXXXX.zip (Broken pipe) for client ptr=0x5609e59ceec0, id=1, addr:xxx.xxx.x.xxx:xxxxx. Terminating This seems to occur in the middle of compressing, not at the end when the temp file should be renamed to the final name. When this error occurs I cannot delete the temp file from Windows. If i delete the file from the /user/ share on unraid it deletes without issue. However Windows can then no longer write a temp file by the same name. It attempts to and it shows in explorer with 0 size and the modified time of when the last file failed. Shutting down my VM and restarting also does not work. The only thing I found that resolves this issue is to completely restart samba. What is going on here and is there a way to tune SMB to prevent this error?

It’s related to memoryBacking. I can reproduce with just that setting and nothing else related to virtiofs

No. Something else is the issue then. In my case I formatted the disk on 6.11.5 as NTFS and it could not be read by a Windows PC. Likewise, a Windows PC formatted NTFS drive could not be read by UD on 6.11.5 until it was formatted.

I just wanted to add a +1 for the issues related to NTFS drives. I had an 18TB Exos drive formatted as NTFS with Windows that would not display as mountable in UD. Since it was basically empty I formatted as NTFS with UD and copied a bunch of data to it as a backup. This drive mounts and works perfectly fine with Unraid, but when I try to connect it to a Windows PC it appears blank like there is no filesystem. Considering I am the 4th person in the past month to mention this issue with NTFS, it really deserves a closer look to see what is going on with this IMO.

Have there been any updates on the freeze issue several people are having whenever memoryBacking is enabled?

snolly's freezing issue was clearly unrelated the the freeze issue most of the people in this thread have. Again the freeze that shows no errors, blue screens, or other indication that anything is wrong is related to the presence of memoryBacking in the config XML. It likely has nothing to do with virtio drivers. Hopefully we hear some kind of a response about this on where to go from here, but for now virtio-fs is not feasible for a lot of people simply because it requires memoryBacking.

I tried Q35 and i440fx snd the results are exactly the same. If memoryBacking is included a freeze will occur within a few hours.

225 solves no relevant issues. According to GitHub 227 should solve permissions problem. I mentioned this in the other topic with a link to the developer comment. I want to reiterate that the freeze occurs for me with every memoryBacking configuration I’ve tried, and has no relation to the presence of the virtiofs configuration in the XML. The freeze occurs even when virtiofs is not used at all. On the windows side everything is perfectly stable and there’s no errors. With the exact same windows setup the freeze will occur whenever memoryBacking is defined. i have no idea what causes this and the logs are useless. If someone has instructions how to turn on better logging I’ll do it. To me this sounds like s lower level bug and isn’t related to virtiofs at all.

Just a quick update, the 225 drivers do NOT resolve the permissions issues if the Virtio-FS service is restarted or started manually. It must still be set to automatic to work properly.

Confirmed 225 is messed up. I think its related to qemupciserial. I was able to install if I deselected that component. Attempting a manual install errors on that component. I suspect it may be using a self-signed certificate or something. Either way I'm giving it a shot. We shall see shortly if the VM freezes... fingers crossed. EDIT: No luck. 225 drivers have the exact same issue and the VM freezes after about 2 hours if memoryBacking is included.

I would suggest a separate post for your issues specifically. This thread is focused on Windows VMs completely freezing (not stuttering) after a few hours on 6.11.1 when trying to use Virtio-FS. Based on my findings so far these freezes are directly related to `memoryBacking` configuration... but no solution yet. Hopefully @SimonF or another developer can help to get this issue into the correct hands.

The fix for now is to automatically start the service and do not restart it. Sounds like there's some pretty complicated logic for determining the user that should be ironed out in the next driver release. https://github.com/virtio-win/kvm-guest-drivers-windows/issues/839

@SimonF - I was able to get the VM to freeze again with just the memoryBacking config in place. I've attached new diagnostics and my VM XML as well. According to the Windows lock screen the freeze occurred around 1:47 PM ET today. The only thing I see in the logs is something like: 2022-10-16 18:16:12.052+0000: Domain id=5 is tainted: custom-ga-command 2022-10-16 18:17:02.245+0000: Domain id=5 is tainted: custom-ga-command 2022-10-16 18:38:28.779+0000: Domain id=5 is tainted: custom-ga-command Each line only appears when trying to view the log from the VMs tab, or trying to shut down the VM normally. As previously mentioned, the only thing that you can do at this point is force stop the VM. If there is a way to enable better logging I am happy to do so to help troubleshoot. tower-diagnostics-20221016-1438.zip johnsanc_win10vm_q35.xml

I'm at my wits end trying to find the best setup for surfacing my shares to my Windows VM. I feel like I've tried everything and every solution falls short. SMB - This works just fine, but the performance is atrocious when working with large directories and many tiny files (which is common for my use case) NFS v3 - This works great and the performance for large directories accessing many small files is orders of magnitude faster than SMB... but does not appear to have UTF-8 support so many of my filenames with Unicode characters can be mangled. NFS v4 - Windows simply doesn't officially support this at all, and I cannot find any client that has decent performance. I tried the one here and it worked, but the performance for large directories was terrible, worse than SMB: http://www.citi.umich.edu/projects/nfsv4/windows/ Virtio-FS - This is apparently bleeding edge and the performance is fantastic, but the memory backing configuration required keeps freezing my VM and no one seems to have a solution for that yet so I can't do much with this until the larger VM freeze issue people are having is resolved. So basically... what do others use and what is the best way to get as much performance as possible for smaller files and large directories?

@SimonF - I will try to reproduce that and provide the logs, however they look the same as the ones I provided in my diagnostics. There is nothing useful in the logs when the freeze occurs at all. Is there any way to enable better debug logging to capture info about the freeze? Also can others following this thread also please try just leaving in the memory backing config and NOT any of the virtiofs stuff to see if you also still observe the freeze? <memoryBacking> <source type='memfd'/> <access mode='shared'/> </memoryBacking>

i tested with VNC only. Same freeze issue if the standard memory backing portion for virtiofs is included.

Virtiofs is CASE SENSITIVE and there is no case insensitive option to use with Windows yet to my knowledge. This could cause issues if code in a game is referring to something.dll, but the file you actually have is something.DLL. Its possible that's what you are running into.

I tried that but I cannot even start the VM with that setting. I get the following error in the popup: Unable to write to file /var/log/libvirt/qemu/Windows 10.log: No space left on device It looks like that config instantly filled up all of the space allocated for logs since the dashboard shows Logs: 100%, yet there isn't much in /var/log at all. Had to reboot because I have no idea how to clear out that memory.