Mailinglist Archive: opensuse-bugs (2150 mails)

< Previous Next >
[Bug 872273] New: Extremely slow reaction of libvirtd after update to Xen 4.3.2_01
  • From: bugzilla_noreply@xxxxxxxxxx
  • Date: Sun, 6 Apr 2014 16:11:38 +0000
  • Message-id: <>

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@xxxxxxxx
ReportedBy: olafmartens@xxxxxx
QAContact: qa-bugs@xxxxxxx
Found By: ---
Blocker: ---

Created an attachment (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

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
2. Log in to a dom0 tty and try to do anything with virsh (like virsh list, et
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,

Configure bugmail:
------- You are receiving this mail because: -------
You are on the CC list for the bug.

< Previous Next >