SPICE Webdavd kills Windows Samba/SMB networking in VM :( -- where to report?

[MrPete]

I've been going crazy...

• Moved my long-stable Retrospect network backup system to a Windows VM
• All kinds of strange anomalies have been seen
• My backup catalog file needs rebuilding... a long/slow process when crunching 17TB of backups, many millions of files and metadata
• I simply could NOT get the rebuild to run to completion. All kinds of errors

Ran a more "thorough" process...and now I saw a reliable, kinda repeatable error:

• The Retrospect rebuild would quit after a few hours, complaining that an SMB network resource (\\nasserver\rsback1) was no longer available
• Very strange: no error on the NAS, no errors on any other machine, no errors on any other VM in fact!
• But this VM had a big red X on a mapped drive to that network share?!
• Simply attempting to reconnect... successfully connects (eg click on the folder in Winexplorer)

After digging in, I realized the following:

• The Windows event log shows loss of that share
• And that event is immediately after an application fault in SPICE webdavd?!
• To make it extra interesting: I do (did) have SPICE installed in the VM... but am not using it. SPICE Webdavd and SPICE Guest Tools.

Below is a sample Event Log entry.
Uninstalled Spice Webdavd and Spice Guest Tools. Now everything is running 100% solid.
(I consider that a workaround, not a solution. I do like SPICE!)

Once my backups are reliable again, I am willing to help diagnose.

Besides reporting this, my main question is: to whom should I report this? Is this related to SPICE (and where are they) or possibly a PVE issue?

Thanks!

---

Faulting application name: spice-webdavd.exe, version: 0.0.0.0, time stamp: 0x5e6fa7d0
Faulting module name: libglib-2.0-0.dll, version: 2.58.3.0, time stamp: 0x00000000
Exception code: 0xc0000005
Fault offset: 0x000000000004e478
Faulting process id: 0x1168
Faulting application start time: 0x01daa44ce3fa9ba3
Faulting application path: C:\Program Files\SPICE webdavd\bin\spice-webdavd.exe
Faulting module path: C:\Program Files\SPICE webdavd\bin\libglib-2.0-0.dll
Report Id: d84565e3-4dc7-4dea-b8fb-a6c5d890639f
Faulting package full name:
Faulting package-relative application ID:

 

[dcsapak]

since it really seems to be an issue with spice itself, https://www.spice-space.org/support.html points to here: https://gitlab.freedesktop.org/groups/spice/-/issues

 

[MrPete]

@dcsapak Dominik,
I've submitted the bug report. I also browsed the spice-devel email list, and overall activity of the project.

UNFORTUNATELY:.

• Did you know: RedHat deprecated SPICE in fall of 2022?!! AND they removed it from RHEL 9. See https://bugzilla.redhat.com/show_bug.cgi?id=2030592#c4
• There really has been no Windows-related SPICE code work since then. (Actually, hardly any since 2018.)
• I am not expecting anybody to pick this bug up.

I would encourage ProxMox to

• Incorporate appropriate notices into the documentation and more about the fact that SPICE is an increasingly unstable platform for remote VM access.
• Look into another alternative. Perhaps a VNC? (I have liked TightVNC for many years but honestly haven't kept up on developments...)

 

[dcsapak]

• Did you know: RedHat deprecated SPICE in fall of 2022?!! AND they removed it from RHEL 9. See https://bugzilla.redhat.com/show_bug.cgi?id=2030592#c4

yes see here: https://forum.proxmox.com/threads/plans-for-spice.113339/

tl;dr we will support the hypervisor side as long as qemu still supports it and it's feasible for us (but ofc we can't look into the future)

• Look into another alternative. Perhaps a VNC? (I have liked TightVNC for many years but honestly haven't kept up on developments...)

vnc in qemu is still supported (you can use it with our webui with novnc) but aside from that there isn't really any current alternative in qemu, so there is not much we can do (short of developing our own protocol, but that would probably a massive undertake, so nothing short/mid term)

 

[MrPete]

tl;dr we will support the hypervisor side as long as qemu still supports it and it's feasible for us (but ofc we can't look into the future)

Thanks.

Well, I do encourage adding documentation about the decline in quality/growing issues. Quite sad... at least RDP is working without breaking the world.