Escalated to Bugzilla from IssueTracker
Cole, is the request to provide kernel/initrd/cmdline parameters for Xen fully-virtualized guests?
Yes, I think that's what it boils down too.
How is this related to passing cmdline parameters? To me it looks like the customer would just like to be able to select a URL for HVM installs from virt-manager (which is a currently grayed out option), rather than install from a locally stored ISO or using PXE (which are not grayed out). As they say correctly, this is already possible with virt-install because when you specify the URL, it goes out and fetches the boot.iso (so it will be temporarily local), and then it does a local iso install.
I realize that also supporting cmdline parameters would even further improve the flexibility of installs (such as giving anaconda a kickstart), but that doesn't seem to be the request here. They just want the same functionality with virt-manager as they already have with virt-install (virt-install doesn't support cmdline parameters for xen hvm guests either).
I could be completely missing something though; so if so, please clarify.
I'm kicking this one back to virt-manager. I don't see any good reason to support the 'fetch boot.iso by url' concept in virt-install, but not in virt-manager.
I think it's not that simple, "fetch boot.iso by URL" as currently implemented in virt-install still cannot include a kickstart file, nor specify the location for install.img and the packages, right?
The solution could be to download the kernel and initrd, and place them on a _custom_ ISO together with an appropriate isolinux configuration file.
I agree with Andrew however: this needs to be implemented in virt-install/virt-manager, not in xen, because it is a workaround that is specific to the installation scenario, and cannot be used in general.
Building custom ISOs is a waste of time. If someone wants to use kernel args, then boot the guest straight off a kernel+initrd instad of using an ISO. This is why I added support for kernel+initrd booting with Xen HVM upstream.
(In reply to comment #11)
> I think it's not that simple, "fetch boot.iso by URL" as currently implemented
> in virt-install still cannot include a kickstart file, nor specify the location
> for install.img and the packages, right?
Right, and I acknowledged this in my initial comment, but the customer didn't mention _anything_ about this in their RFE, and in fact said "virt-install works". So we just need to mimic the behavior they like in virt-install in virt-manager, and it's a done deal. A note above the virt-manager URL option saying that it's going to grab "a minimal boot ISO image" from the given URL should be sufficient for clarity about what it's going to do. I got the "a minimal boot ISO image" verbiage from the virt-install man page.
I think we need to hear from the customer. When they say 'virt-install has the option', have they actually verified this works? If so, what are they doing here:
virt-install --cdrom http://foo/bar...
virt-install --location http://foo/bar...
The former pulls down a boot.iso from the tree, and I think should already work in virt-manager: just enter the install tree URL in the local ISO text field. The UI could make this more explicit.
The latter pulls down kernel/initrd, and can acknowledge --extra-args option for use of kickstarts, etc. Upstream xen supports this, but I believe it has been technically rejected for RHEL5 given the risk of backporting the change.
So, what behavior is the customer looking for here?
Actually both those virt-install options do the same thing for Xen HVM guests. From the virt-install code
# RHEL HACK: Restore previous behavior for xen HVM installs, where
# --location == --cdrom for URLs
if ishvm and virtinst.util.get_uri_driver(guest.conn.getURI()) == "xen":
guest.installer.cdrom = True
Cole pointed out that a URL can be put in the ISO text field of virt-manager already. Possibly the customer doesn't know that (I didn't). Maybe just passing this information on to the customer will be sufficient to satisfy their needs.
(In reply to comment #16)
> Cole pointed out that a URL can be put in the ISO text field of virt-manager
> already. Possibly the customer doesn't know that (I didn't). Maybe just passing
> this information on to the customer will be sufficient to satisfy their needs.
Well, for URL install of HVM guest instead of selecting the ISO image I gave the URL location there, i.e. something like http://server/install/x86_64/os/ and it automatically downloaded the boot.iso image from images/boot.iso of the tree. When I selected the install option of the guest the guest was asking for the installation source, i.e. CD-ROM, hard-drive or exported NFS/HTTP. In the virt-manager the CD-ROM mounted was /var/lib/xen/virtinst-boot.iso.XXXXXX where XXXXXX seems to be random characters available for path like used in mkstemp() function for C language so basically virtinst downloads the boot.iso file automatically for the used when URL is being entered (instead of ISO) so basically we should document that for URL install for HVM guests is possible since it seems that virtinst downloads the boot.iso image itself.
Andrew, huh, I forgot about that hack. So yeah, I guess this is just about advertising in virt-manager that we can pull a boot.iso from a URL, and verifying that it works.
Created attachment 442222 [details]
Advertise FV CDROM URL installs
We now enable the URL install options for FV guests, but disable the kernel/kickstart options and show a warning explaining that they don't work for Xen FV.
Fixed in virt-manager-0.6.1-13.el5
On host rhel5u5.
#rpm -q virt-manager
The network installation option of virt-manager can be selected, and guest can be installed well.
Verified on RHEL5u6
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
URL installation options for fully virtualized guests have been enabled in Virtual Machine Manager. This is accomplished by fetching a boot.iso disc image from the URL install tree.
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.