This is with libvirt 0.9.0..4 and xen 4.1.0..1 at least. Observe: asuffield@dock:~$ sudo xenstore-read /local/domain/1/vm /vm/3f0bbb2b-3ae8-7bfc-53cf-e22ac61d717b asuffield@dock:~$ sudo xenstore-read /local/domain/2/vm /vm/b89bd689-80ae-9b05-4b0e-d156889c39c8 asuffield@dock:~$ sudo xenstore-read /local/domain/0/vm /vm/00000000-0000-0000-0000-000000000000-24 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; VIR_FREE(name); continue; } 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.
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