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