Description of problem: Install of virtual guest fails due to libvirt error Version-Release number of selected component (if applicable): libvirt-0.3.3-7.el5 virt-manager-0.5.3-8.el5 How reproducible: Always 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. Actual results: Error Expected results: Guest install starts Additional info: 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 self.connections[uri]["connection"].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 libvirt hash
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 release.
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 libvirt-0.3.3-7.el5 virt-manager-0.5.3-8.el5 [root@test2 ~]# cat /etc/redhat-release Red Hat Enterprise Linux Server release 5.2 (Tikanga) [root@test2 ~]# 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. Daniel
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 domain: ---------------- virt-manager log -------------------------- [...] [Tue, 17 Jun 2008 17:06:05 virt-manager 6450] DEBUG (create:548) Creating a VM s2 Type: xen UUID: 3ab825f8-c764-b706-9829-8d6e1f783a11 Source: http://192.168.0.12/RHEL5/ OS: Generic Kickstart: Memory: 512 Max Memory: 512 # VCPUs: 1 Filesize: 4.8828125 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 selected [....] [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. Daniel Daniel
Daniel, 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, Daniel
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, thanks Daniel
We were unable to reproduce, so closing the bug at this point, Daniel