On Monday, February 6, 2012 at 2:55 PM, Cole Robinson wrote:
On 02/06/2012 12:34 PM, Michael DeHaan wrote:
On Monday, February 6, 2012 at 11:37 AM, Cole Robinson wrote:
On 02/06/2012 10:58 AM, Michael DeHaan wrote:
Cole --
What's the workaround to auto-start Xen PV's? (or is there not a way?)
Seems like we could just implement this however needed (if xenpv… do this instead…), if virtinstall won't do it for us.
The autostarting code could just be conditionally enabled if virt-install is new enough (just a grep of the help output) so that's not the issue.
The issue is that current koan code manually passed a kernel + initrd for the PV guest to boot. That's the only install scenario for PV guests AFAICT. And this is only available via the virt-install in a version newer than what's in RHEL5.
That's also how the virt installs work for everything else in koan, including qemu/KVM.
(Maybe I'm misunderstanding something?)
This is my understanding of the current code.
Xen FV: always does a PXE boot (so guest is actually talking to PXE server): https://github.com/cobbler/cobbler/blob/master/koan/xencreate.py#L80
Xen PV: Libvirt tells the guest to boot directly off the kernel/initrd pair specified in profile_data["kernel_local"] and profile_data["initrd_local"]: https://github.com/cobbler/cobbler/blob/master/koan/xencreate.py#L88
(are those kernel_local + initrd_local values filled in by cobbler or does the user need to manually specify them?)
QEMU/KVM has two install options:
if profile_data["file"] is present, boot off it like a cdrom: https://github.com/cobbler/cobbler/blob/master/koan/qcreate.py#L101
Don't think I care about this one, meaning I think we could get rid of it.
if profile_data["install_tree"] is present, pass the URL off to virtinst and have it use it's tree probing to fetch kernel + initrd: https://github.com/cobbler/cobbler/blob/master/koan/qcreate.py#L121
Ugh yes, I believe that was required as it didn't support the other at the time or something. It has been a while. I had to work around a lot of inconsistencies and seem to recall thinking it was easier than it was :)
My implementation preserves this behavior, but in reality Xen FV and Qemu can
all boot from tree/kernel, cdrom, and pxe. Xen pv can only boot from tree/kernel (which is the same thing basically).
Requiring PXE is disadvantageous to those that don't have DHCP, so yeah, I don't think that should be the default way.
My suggestion was to adapt xen pv to behave as qemu does with "install_tree".
Sounds reasonable.
The workaround could be to make PV installs work like qcreate install_location installs, which is basically the same as direct kernel/initrd boot but you rely on virt-install to pull the kernel/initrd from the install tree.
Just trying to make sure this wouldn't break anyone.
The install tree location isn't actually required in Cobbler, it's only a parameter to the kickstart … Are you saying we'd have to use the install tree method *only* for Xen PV? If so, that might be an acceptable limitation… if Xen FV or qemu/KVM requires the tree to find the kernel/initrd that seems bad to me, because we deal with a lot of arbitrary distros that express install tree locations in different ways.
ks_meta["tree"] gives you this if someone had ran "Cobbler import" previously.
If we can avoid using that when we don't have to, that would be good…
Since cobbler tracks this info it would probably 'just work' with a tiny patch but someone would need to test. And this has been supported on virt-install command line since probably rhel5.1
"it" == making autostart work for Xen PV, right?
No, autostart is not the issue here. The issue is getting guests to actually install. The autostart piece is just recent functionality to cobbler that currently brok all installs on RHEL5 host. Fixing this would be a fairly trivial patch on top of current koan or my code.
The more interesting piece is making xen PV installs actually work on RHEL5 where virt-install is not new enough to provide the cli option needed to have parity with current xen PV installation, which requires passing a local kernel
- initrd path to boot from.
Sorry if that isn't clear.
nod, ok, all sounds reasonable -- send me a pull request or whatever with what you think sounds reasonable -- ideally after trying it out live, and we'll merge it in.
Thanks for the explanations.
Thanks, Cole