Bug 733319 - Weird xen not-so-uuids cause libvirtd to delay new connections
Summary: Weird xen not-so-uuids cause libvirtd to delay new connections
Alias: None
Product: Virtualization Tools
Classification: Community
Component: libvirt
Version: unspecified
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2011-08-25 13:15 UTC by asuffield
Modified: 2016-03-23 13:38 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2016-03-23 13:38:42 UTC

Attachments (Terms of Use)

Description asuffield 2011-08-25 13:15:11 UTC
This is with libvirt 0.9.0..4 and xen 4.1.0..1 at least.

asuffield@dock:~$ sudo xenstore-read /local/domain/1/vm
asuffield@dock:~$ sudo xenstore-read /local/domain/2/vm
asuffield@dock:~$ sudo xenstore-read /local/domain/0/vm

That last one isn't even close to a valid UUID, not least because it is 34 bytes long. This makes xenStoreDomainIntroduced unhappy here:

            if (xenStoreDomainGetUUID(conn, new_domids[i], uuid) < 0) {
                missing = 1;

It will always consider domain 0 to be "missing", so will always delay for 2 seconds of retries.

Xen's silly data should be tolerated or ignored, not cause a retry loop.

Comment 1 Cole Robinson 2016-03-23 13:38:42 UTC
Sorry this never received a response. You're right that bogus xen data shouldn't cause us issues here, but given that the xend/xenstore libvirt bits aren't as commonly used these days (over libxl), and I suspect xen eventually fixed their side, I doubt this will be fixed in libvirt unless someone sends a patch.

If anyone is still hitting this issue with recent libvirt, please reopen this bug and I can ping one of the xen devs. Until then closing as DEFERRED

Note You need to log in before you can comment on or make changes to this bug.