https://bugzilla.novell.com/show_bug.cgi?id=872273 https://bugzilla.novell.com/show_bug.cgi?id=872273#c0 Summary: Extremely slow reaction of libvirtd after update to Xen 4.3.2_01 Classification: openSUSE Product: openSUSE 13.1 Version: Final Platform: x86-64 OS/Version: openSUSE 13.1 Status: NEW Severity: Major Priority: P5 - None Component: Xen AssignedTo: jdouglas@suse.com ReportedBy: olafmartens@web.de QAContact: qa-bugs@suse.de Found By: --- Blocker: --- Created an attachment (id=585252) --> (http://bugzilla.novell.com/attachment.cgi?id=585252) List of all installed packages related to Xen and libvirt User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 After Xen has been updated to 4.3.2_01 (however, some packages for Xen are still 4.3.1 and even 4.3.0) libvirtd displays extremely long response times despite any autostart VMs booting up like always, which is unusual, as normally it comes up much quicker. I get an XDMCP login to the Linux domU relatively quickly (in case the VM has previously been suspended, it is instead booted as if it hasn't been suspended in the first place, and when libvirtd tries to resume the machine after a significant delay, it already finds the VM running and dismisses the resume attempt), but trying to do anything with virsh initially requires an extremely long time (about 5 mins+) to get any reaction at all (I used virsh list for verification purposes). Furthermore, when attempting to connect with virt-manager to dom0 via port 16509 I get the same long timeouts, and even if I get the connection established, the connection repeatedly times out due to the extremely long response times. Same game when shutting down: When attempting to suspend a domU without any of them running, the process that attempts to initiate the suspend fails to attach to libvirtd fails and gives up after ten attempts. Strangely enough, if a domU is running, it is suspended normally. Reproducible: Always Steps to Reproduce: 1. Start up a machine with a Xen-aware dom0 (one domU should be flagged as autostart) - XDMCP login to the domU recommended (to quickly get access to the domU). 2. Log in to a dom0 tty and try to do anything with virsh (like virsh list, et al.). 3. From the domU you have logged in to via XDMCP (or from a remote machine) try to connect virt-manager to libvirtd. 4a. Shut down ALL running domU (e. g. from the K menu), and after the domU has powered off, shut down the physical box. Alternate path: 4b. Power off the physical box with any domU still active. They are going to be suspended normally. 5b. Power on the physical box. Actual Results: Long timeouts, slow reactions and lost connections when working with virt-manager et al. Furthermore, if any VMs are suspended upon the previous shutdown of the physical box, the auto-resume is initiated a significant amount of time after libvirtd has been started, therefore the virtual box has already been booted normally, and the resume is dismissed. Expected Results: Normal boot-up procedure, i. e. libvirtd is available after only a small delay (i. e. a few seconds), plus firing up the physical box has to resume any suspended VMs instead of spuriously booting them. It appears as if something in Xen and/or libvirtd is using up a significant amount of time, thereby causing extreme delays and, as a final consequence, timeouts. -- 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.