Red Hat Bugzilla – Bug 450511
libvirt.libvirtError virDomainLookupByID() failed internal error domain information incomplete, missing name
Last modified: 2009-12-14 16:23:19 EST
Description of problem:
Install of virtual guest fails due to libvirt error
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Start virtual-manager and connect to localhost
2. create new PV guest - name is "s1"
3. after install is completed boot the guest and shut it down (may not be necessary)
4. create a new guest with name "s2". point it to use the same disk image as s1
5. Upon clicking Finish the error occurs.
Guest install starts
After examining virt-manager.log I see repeating error block as shown below.
further more the end of the stack trace is similar to the error shown in UI and
I believe this to be the root cause of the problem.
[Mon, 09 Jun 2008 07:10:15 virt-manager 4303] ERROR (engine:156) Could not
refresh connection xen:///
libvirt.libvirtError virDomainLookupByID() failed internal error domain
information incomplete, missing name
Traceback (most recent call last):
File "/usr/share/virt-manager/virtManager/engine.py", line 152, in _tick
File "/usr/share/virt-manager/virtManager/connection.py", line 555, in tick
vm = self.vmm.lookupByID(id)
File "/usr/lib/python2.4/site-packages/libvirt.py", line 638, in lookupByID
if ret is None:raise libvirtError('virDomainLookupByID() failed', conn=self)
libvirtError: virDomainLookupByID() failed internal error domain information
incomplete, missing name
Does this have something to do with bug #448533: conflict between domains in
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
I don't understand, if I try this after creating the new guest and
providing the same path for the disk image I get a big popup
Disk "/virt/s1.img" is already in use by another guest
Do you really want to use the disk ?
[No] / yes
if I click on [yes] I get the RHEL-5 ISO image boot prompt, and it
asks me if I want to skip the media tests...
So by following your reproduction procedure I apparently don't
get the same output.
[root@test2 ~]# virsh list
Id Name State
0 Domain-0 running
3 backup blocked
[root@test2 ~]# rpm -q libvirt virt-manager
[root@test2 ~]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 5.2 (Tikanga)
Can you provide exactly the steps you used for reproducing the problem ?
Somehow I feel you didn't do exactly the steps provided, right ? Or there is
something missing in the steps, because "Always' doesn't work for me on my
remote RHEL-5.2 box.
I re-retried this, making sure to use paravirt, go though exactly (???)
all the steps, checked the logs, everything starts fine once I say
yes to the popup warning me that the disk is already in use by another
---------------- virt-manager log --------------------------
[Tue, 17 Jun 2008 17:06:05 virt-manager 6450] DEBUG (create:548) Creating a VM s2
Max Memory: 512
# VCPUs: 1
Disk image: /data/s1.img
Non-sparse file: True
[Tue, 17 Jun 2008 17:06:05 virt-manager 6450] DEBUG (create:568) Non-sparse file
[Tue, 17 Jun 2008 17:06:06 virt-manager 6450] DEBUG (manager:408) About to
append vm: s2
[Tue, 17 Jun 2008 17:06:06 virt-manager 6450] DEBUG (manager:398) VM s2 started
[Tue, 17 Jun 2008 17:06:06 virt-manager 6450] DEBUG (Guest:839) Created guest,
looking to see if it is running
[Tue, 17 Jun 2008 17:06:06 virt-manager 6450] DEBUG (Guest:863) Saving XML boot
config '<domain type='xen'>
seems the installer started just fin e on the new domain, i really
could not reproduce this (fully updated X86_64 RHEL-5.2).
If you can still reproduce this what i can do is build a RHEL-5.2 derived
libvirt package with the fix for 448533 and let you do the test.
I wasn't able to reproduce consistently after the report was filed. I saw the
issue a couple of times while performing other work. I'll try testing on the
exact same machine and distro version in the following days. Hope to find the
root cause of this.
Well I think I will build a new test package with the fixes for 5.3,
then if you can do testing with it this may help ensure it's fixed.
The problem may be related to the hash table clash list, and that
list may grow automatically, so it's possible this is the issue but
happen only when the hash table grow to a given size, hence becoming
reproductive systematically on that given libvirtd but if you restart
from scratch it doesn't happen anymore.
I will provide a link when I have a new package to test,
Alex, if you could try with libvirt-0.3.3-8.el5, hopefully it has
the fix for that bug. You can find it in dist-5E-qu-candidate,
We were unable to reproduce, so closing the bug at this point,