Description of problem: Using virt-manager or virt-install in RHEL 5.1 beta, I cannot build a vm from the URL (Install Media) provided by Red Hat Satellite Server 4.2.2. Virt-manager/virt-install from RHEL 5.0 are able to successfully build from the same URL on the Satellite server. Version-Release number of selected component (if applicable): These don't work: python-virtinst-0.103.0-2.el5 virt-manager-0.4.0-2.el5 python-virtinst-0.200.0-3.fc7 virt-manager-0.4.0-2.fc7 These versions work: python-virtinst-0.99.0-2.el5 virt-manager-0.2.6-7.0.2.el5 How reproducible: Always. Steps to Reproduce: 1) Launch virt-manager and in the screen that asks you for the Install Media, input the tinyurl generated by satellite for accessing the kickstart-able install tree. 2) In the kickstart, provide the URL of the Bare Metal Kickstart as specified by the Satellite server kickstart profile. 3) Continue the installation... Actual results: virt-manager/virt-install in RHEL 5.1/Fedora 7 issue a GET /ty/<random_url>/ and the Satellite server responds with a 404 (page not found) message and the install fails. Expected results: virt-manager/virt-install issue a GET /ty/<random_url>/images/xen/vmlinuz to pull down the kernel and later the initrd so that the installation can continue. This was the behavior with RHEL 5.0 virt-manager. Additional info:
Please provide the *EXACT* virt-install command line you are running. Also, run virt-install with the --debug flag added & paste the complete output into this ticket. For virt-manager attach, /root/.virt-manager/virt-manager.log
Created attachment 234611 [details] Virt-manager log from rhel 5 showing successful install start.
Created attachment 234621 [details] Virt-manager log from rhel 5.1 beta showing install start failure.
Created attachment 234631 [details] tcpdump from rhel 5.0 client.
Created attachment 234641 [details] tcpdump from rhel 5.1 client.
Please see this test case I have run. In both cases, the same Dom0 is accessing the same satellite server. The URL it should be using to pull down the kernel and initrd for the installer to run is found at http://satellite.battlestar.local/ty/ioBUribl In RHEL 5.0 (as seen in the tcpdump), urlgrabber issues GET http://satellite.battlestar.local/ty/ioBUrib1/images/xen/vmlinuz In RHEL 5.1 (see tcpdump), urlgrabber issues GET http://satellite.battlestar.local/ty/ioBUrib1 to which the satellite server responds with a 404. Looks like in 5.1, the url, urlgrabber is trying to get is truncated.
The URL is not truncated. This is a delibrate fetch to validate the install base URL actually exists we fetch the root URL. We need todo this because virt-install has to cope with my different kinds of distro & can't blind go straight for the images/xen/vmlinuz file. The logs show satellite is giving back: http://satellite.battlestar.local/ty/ioBUribl [Errno 14] HTTP Error 404: Not Found Any valid installation tree must always return content for this URL, since at the very least the distro base has the directories for RPMs, and the kernel images. Satellite is giving back a bogus Error 404 for the base distro tree & thus we do not find a valid distro present. Satellite needs to be fixed to return valid content for the base URL, ie a 200 OK code, not a 404 not found.
There are two options for python-virtinst here really - Remove/re-write the code which checks the base URL. This will remove some of the error reporting capabilities we added. - In the code which catche the 404, put in some check against the HTTP response headers to identify & special case handling for RHN. Both have some element of risk, the second option is probably less risky though because it won't result in significant changes to the non-RHN based provisioning on virtual machines. Neither of these are suitable for 5.1 day-0 errata because from painfull experiance (this ticket included), everytime we change something in this bit of code, an unexpected thing breaks. Thus any change here will require significant testing to ensure we don't cause regressions.
using wget -S doesn't seem to show any rhn specific information in the http headers from a 404 response. An interesting thing though: if the link to a tree generated by rhn is still valid, attempting to access it throws a 404 error. If this link has expired, no 404 error is thrown, just a redirection to a generic 404 page. As such, trying to run virt-install on an expired link bypasses this error, downloading the 404 page as the intended file, and then barfing when it tries to use said file as a kernel etc.
Does anyone on the rhn side know of a way to determine if an install tree is being managed by a satellite server? Is there a satellite specific file we can check for, or maybe even anything to determine the system in general is running satellite? We would like to be able to do a one-off check to see if we are talking to a satellite server if the tree URL resolution fails, so that we can safely ignore the error.
Created attachment 245821 [details] Patch for python-virtinst against rhel5 cvs
patch in comment #23 works for me with a 5.1 client and Satellite Server 4.2.2. Thanks!
hi, I experienced the same problem, and after using the patch it worked fine for me. But, when I try to do a virt-install for a paravirtualized RHEL4 system, it fails again. Is it possible to make a workaround for that as well???
output of virt-install of rhel4 installation tree. [root@inc0002 /]# virt-install --name=inv0010 --ram=2048 --vcpus=2 -- file=/sysmnt/inv0010/inv0010.img --file-size=30 --bridge=xenbr0 --accelerate -- paravirt --location=http://inv0001.nxdi.nl-htc01.nxp.com/ty/DRyo31R9 --extra- args="ks=http://inv0001.nxdi.nl-htc01.nxp.com/kickstart/ks/label/emea01-vhost-4- 64 ip=134.27.193.38 netmask=255.255.255.0 gateway=134.27.193.1 dns=134.27.192.20 ksdevice=eth0" --debug Would you like to enable graphics support? (yes or no) yes Starting install... Fri, 14 Dec 2007 15:43:05 DEBUG Validation failed for http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9 [Errno 14] HTTP Error 404: Not Found Fri, 14 Dec 2007 15:43:05 DEBUG Tree URL could not be opened. Checking ahead for valid RH distro. Fri, 14 Dec 2007 15:43:05 DEBUG Fetching URI http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9/Fedora Fri, 14 Dec 2007 15:43:05 DEBUG Cannot find file Fedora Fri, 14 Dec 2007 15:43:05 DEBUG Fetching URI http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9/centosdocs-man.css Fri, 14 Dec 2007 15:43:05 DEBUG Cannot find file centosdocs-man.css Fri, 14 Dec 2007 15:43:05 DEBUG Fetching URI http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9/RPM-GPG-KEY-redhat-release Fri, 14 Dec 2007 15:43:05 DEBUG Cannot find file RPM-GPG-KEY-redhat-release Fri, 14 Dec 2007 15:43:05 DEBUG Fetching URI http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9/autorun Fri, 14 Dec 2007 15:43:05 DEBUG Saved file to /var/lib/xen/virtinst- autorun.eNzgCu Retrieving autorun... 100% |=========================| 248 B 00:00 Fri, 14 Dec 2007 15:43:05 DEBUG Fetching URI http://inv0001.nxdi.nl- htc01.nxp.com/ty/DRyo31R9/RPM-GPG-KEY Fri, 14 Dec 2007 15:43:05 DEBUG Saved file to /var/lib/xen/virtinst-RPM-GPG- KEY.3ytil6 Retrieving RPM-GPG-KEY... 100% |=========================| 1.9 kB 00:00 Fri, 14 Dec 2007 15:43:05 DEBUG Detected a RHEL-4 distro ERROR: Invalid install location
Created attachment 289501 [details] Fix xen guest installs against Satellite The previous attached patch is buggy wrt to RHEL4 - attaching the patch we actually applied to the RPMS.
Correct me if I'm wrong, but with Bugzilla Bug 412061 in a CLOSED ERRATA state, and RHBA-2008:0026 - Bug Fix Advisory out: https://rhn.redhat.com/rhn/errata/details/Details.do?eid=6523 http://rhn.redhat.com/errata/RHBA-2008-0026.html is there still a bug in Satellite/Hosted to fix? Or can we call this notabug or a dupe of bug 412061?
Satellite must still be fixed. We merely put a hack into virt-install to workaround the RHN limitation in the short term. This hack is not suitable for feeding upstream, so long term it is desirable to get RHN Satellite correctly responding to HTTP GET's on the install trees so they are browsable in the same way as normal non-RHN install trees. Without such a fix its inevitable that this or similar problems will recurr.
Created attachment 291668 [details] Log snippet of /root/.virt-manager/virt-manager.log Attempting to install via localized media as the help file instructs.
Also unable to install via locally mounted media. log snippet indicates it's looking for files to identify a valid install, however it does not find CentOS, Fedora, and attempts to look for RHEL media, and unable to locate autorun. Using RHEL 5.1 DVD media. Have attempted using subdirs Server, VT, etc, same result. Log snippet attached.
Jim, I believe this is a seperate issue. Could you file a new bug for this please, including the above log and any other info that might help. Thanks!
Will do
going to get this into sat510 branch
qa test plan: 1) create a kickstart profile 2) copy the distribution url that is part of the kickstart profile, i.e. something like, http://shaggy.rdu.redhat.com/ty/aQb9OYHs 3) the url above points to a distribution tree on the satellite 4) try using wget to grab the content, u should see a 200 response 5) now trying to add a directory to the url, for example on a rhel 4 tree this is possible, http://shaggy.rdu.redhat.com/ty/aQb9OYHs/RedHat. confirm again a 200. 6) now trying pinging a bogus directory, http://shaggy.rdu.redhat.com/ty/aQb9OYHs/RedHats, you should see a 404
mass move to onqa
actually ran the whole virt guest install from virt-manager w/ the urls provided by an rhn kickstart.. works great.. good job..
1) took existing rhel5 kickstart profile 2) copied dist url: http://test10-64.rhndev.redhat.com/ty/UjjsThDC 3) ran wget against url got a 200 response 4) ran wget against url with directory: http://test10-64.rhndev.redhat.com/ty/UjjsThDC/RedHat - results in 404 which is expected because this is a RHEL5 kickstart http://test10-64.rhndev.redhat.com/ty/UjjsThDC/Fedora - results in 404 which is expected because this doesn't exist http://test10-64.rhndev.redhat.com/ty/UjjsThDC/Server - results in 200 expected because this is a RHEL5 kickstart release pending.
5.1 Sat GA so Closed for Current Release.