Red Hat Bugzilla – Bug 494884
Guest Provisioning doesn't work if the host was provisioned
Last modified: 2009-09-10 15:24:56 EDT
When provisioning a guest, it will fail because it can't find the cobbler system record if you the host was previously provisioned.
Steps to reproduce:
1. Register a virt host
2. Reprovision the virt host
3. Try to deploy a guest to the host
The cause of this is that the guest system record isn't created if the host has a system record.
commited but leaving as modified until i can test it a bit better
Another small fix
VERIFIED on 6/12 build.
It appears that this issue has reappeared in the 6/19 ISO, so I'm moving this over to FAILS_QA. For more information, consult bug 507669.
*** Bug 507669 has been marked as a duplicate of this bug. ***
Also got the following whilte trying to provision a xen guest on host which was kickstarted from the satellite.
Details: This action will be executed after 06/25/09 10:38:01 AM EDT.
This action's status is: Failed.
The client picked up this action on 06/25/09 10:38:27 AM EDT.
The client completed this action on 06/25/09 10:38:35 AM EDT.
Client execution returned "Virtual kickstart failed. Koan error.: POST operation failed: (xend.err 'Device 0 (vif) could not be connected. Could not find bridge device xenbr0') File "/usr/share/rhn/spacewalkkoan/spacewalkkoan.py", line 129, in initiate_guest k.run() File "/usr/lib/python2.4/site-packages/koan/app.py", line 312, in run self.virt() File "/usr/lib/python2.4/site-packages/koan/app.py", line 601, in virt return self.net_install(after_download) File "/usr/lib/python2.4/site-packages/koan/app.py", line 520, in net_install after_download(self, profile_data) File "/usr/lib/python2.4/site-packages/koan/app.py", line 599, in after_download self.virt_net_install(profile_data) File "/usr/lib/python2.4/site-packages/koan/app.py", line 1080, in virt_net_install virt_type = self.virt_type File "/usr/lib/python2.4/site-packages/koan/xencreate.py", line 179, in start_install guest.start_install() File "/usr/lib/python2.4/site-packages/virtinst/Guest.py", line 822, in start_install " (code 1)
operation failed: (xend.err 'Device 0 (vif) could not be connected. Could not
find bridge device xenbr0') File
seems to indicate that 'xenbr0' is not present on that virt host. Can you run 'ifconfig' and verify that? If that's the case, then you would just need to specify whatever virt bridge that host does have in the advanced options page when doing the provisioning.
So i'm going to move this to On_qa if you want to test it again, but the error in comment #6 isn't related to this bug.
I will retest this
There's still one problem ...
I successfully kickstarted a host, but when I wanted to provision a guest, the event ("Initiate a kickstart for a virtual guest. scheduled by admin") failed with:
Details: This action will be executed after 07/16/09 9:18:44 AM EDT.
This action's status is: Failed.
The client picked up this action on 07/16/09 9:19:00 AM EDT.
The client completed this action on 07/16/09 9:19:07 AM EDT.
Client execution returned "Virtual kickstart failed. Koan error.: invalid location: /var/lib/libvirt/images/para_guest0" (code 1)
The problem is following:
# ll /var/lib/libvirt/images/
ls: /var/lib/libvirt/images/: No such file or directory
# ll /var/lib/libvirt/
-rw-r--r-- 1 root root 0 Jul 15 16:48 dhcp-default.leases
So, I created the images directory:
# mkdir /var/lib/libvirt/images/
and rescheduled the failed event. Then the kickstart worked well and the guest was successfully provisioned.
Another issue is at the end of the kick start, when the guest shall be rebooted. It was halted instead of the reboot. But this is another issue and it shall be handled by another BZ.
Tested with Satellite-5.3.0-RHEL5-re20090707.0.
Preethi is welcome to retest it.
That issue really doesn't have anything to do with this bug. It is a side effect of this:
So either a new bug probably needs to be created, or that bug should be failed.
OK Justin, I agree. I created BZ#512679 regarding the problem described in Comment#10. Since that problem is only a missing directory issue and after you create it manually it is possible to successfully finish the provisioning, your fix has to work.
I didn't see any cobbler records issues, what was the original bug report about.
Verified with Satellite-5.3.0-RHEL5-re20090716.0.
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.