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?)
 

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?
 

Thanks,
Cole