[Bug 885918] New: libvirtd/libxl: Stopping/restarting or rebooting is likely to cause libvirtd/libxl to hang, but any running VMs still remain operable
https://bugzilla.novell.com/show_bug.cgi?id=885918 https://bugzilla.novell.com/show_bug.cgi?id=885918#c0 Summary: libvirtd/libxl: Stopping/restarting or rebooting is likely to cause libvirtd/libxl to hang, but any running VMs still remain operable Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xen AssignedTo: jdouglas@suse.com ReportedBy: olafmartens@web.de QAContact: qa-bugs@suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:30.0) Gecko/20100101 Firefox/30.0 Whenever any virtual machine is stopped, there is a certain risk that libvirtd is going to hang, leaving the connection from virt-manager to it (via TCP/SASL) dangling, thereby locking virt-manager up (i. e. it doesn't get any status info on the VMs, and its built-in VNC client ceases to function as well). A side effect of this is that whenever a virtual machine fires up, libvirtd very often terminates the TCP connection from virt-manager which then has to be reestablished manually. A restart of libvirtd and subsequent reconnection of virt-manager is required to get things unstuck, because this also kills the unresponsive TCP connection. However, in that event systemd has to wait on the timeout for SIGTERM (about 1 min.) and forcibly shut it down with SIGKILL. Fortunately any VMs that are up continue to operate and can be worked with normally. Switching to an alternate VNC client confirms this (video data continues to be transmitted). I need some more testing, but the way I take it, Windows VMs are more prone to this malady than the Linux VMs I have set up. In fact, I can reboot my workspace VM multiple times in a sequence without any harm being done (I'm accessing it via XDMCP, not via VNC, plus said domU doesn't have a video device or frame buffer set up). Reproducible: Sometimes Steps to Reproduce: 1. Fire up a VM and connect virt-manager to the VNC frame buffer. 2. Stop/restart or reboot said virtual machine. 3. Repeat until the hang occurs (should happen after a few restarts). 4. Invoke systemd restart libvirtd.service to get things unstuck.'once the hang occurs. Actual Results: virt-manager gets stuck and has to be forcibly unstuck by shutting down the dangling TCP connection. This can be achieved by restarting libvirtd; attempting to shut the connection down on the client side doesn't work (it won't do so by itself, and killing virt-manager and restarting it, then attempting to reconnect to libvirtd causes virt-manager to hang again). Expected Results: libvirtd should continue to operate normally, without any hangs. I have dug through the logs, but unfortunately I couldn't find any helpful information on this issue so far. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=885918 https://bugzilla.novell.com/show_bug.cgi?id=885918#c Charles Arnold <carnold@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |carnold@suse.com AssignedTo|jdouglas@suse.com |jfehlig@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=885918 https://bugzilla.novell.com/show_bug.cgi?id=885918#c1 --- Comment #1 from Olaf Martens <olafmartens@web.de> 2014-07-07 14:53:53 UTC --- Supplemental: It seems that only VMs that provide a graphical console (VNC) are affected by this, because when I started up a VM without, everything went fine, and virt-manager stayed attached to libvirtd. This didn't change with repeatedly shutting down and relaunching said VM. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com