eucalyptus should support booting multiboot image

[Scott Moser]

Currently, for each instance launched by Eucalyptus, an admin provided kernel is booted. Eucalyptus generates a hunk of libvirt xml like the following:
    <os>
    <type>hvm</type>
        <kernel>BASEPATH/kernel</kernel>
        <cmdline>root=/dev/sda1 console=ttyS0</cmdline>
    </os>

The result is that kvm is invoked with '-kernel <path/kernel>' and '-append root=/dev/sda1 console=ttyS0'.

Historically, the admin provided kernel has been a linux kernel. This is in keeping with EC2's practice. Recently, amazon has exposed the ability to "boot your own kernel" by providing pv-grub as a "kernel". The pv-grub boot loader functions very much like a normal "grub 0.97" loader. It reads a menu.lst from /boot/grub/menu.lst and boots kernels from inside the guest.

The largest end user benefit of this is that now the operating system booted can manage its own kernel. Previously, a kernel upgrade in an instance would result in the same kernel being used on reboot.

Eucalyptus should provide a way to load a boot loader, rather than limiting the 'kernel' to a linux kernel.

===

The truth is, that Eucalyptus does not enforce that the kernel must be a linux kernel. And, a multiboot complient kernel can actually be booted in the mechanism described above, thanks to kvm '-kernel' being a multiboot complient boot loader.

This sounds like a perfectly simple solution: Let the admin create multiboot compliant boot loader image (ie, grub2) that would chainload to the grub installed in the image.

In fact, it actually *almost* works. The problem with the simple solution is that eucalyptus uses scsi as its root device, and seabios has no native support for scsi (bug 611142).

Because this is *major* functionality, I'm seeking a work around to the issue above.

--
[1] http://aws.typepad.com/aws/2010/07/use-your-own-kernel-with-amazon-ec2.html

ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: eucalyptus-nc 2.0~bzr1211-0ubuntu1
ProcVersionSignature: User Name 2.6.32-305.9-ec2 2.6.32.11+drm33.2
Uname: Linux 2.6.32-305-ec2 i686
Architecture: i386
Date: Thu Jul 29 03:15:18 2010
Ec2AMI: ami-e930db80
Ec2AMIManifest: ubuntu-images-testing-us/ubuntu-maverick-daily-i386-server-20100727.manifest.xml
Ec2AvailabilityZone: us-east-1b
Ec2InstanceType: m1.small
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/bash
SourcePackage: eucalyptus

[Dave Walker (davewalker)]

@Scott, Can you clarify that the proposed fix for now is to:
Make a floppy containing a pv-grub bootloader?

If this is the case, can you confirm that it shouldn't regress images not containing a floppy?

Thanks

[Scott Moser (smoser)]

The intent is to not regress existing images.
The protection against doing so is:
if (kernel file looks like a linux kernel) or (virtio root); then
  use old path
else
  load the aki payload via multiboot from a floppy
fi

I would like to change that to be:
if (kernel file is a multiboot compliant image) and (!virtio root); then
  load the aki payload via multiboot from a floppy
else
  use old path
fi

The problem right now is that I do not have a good check for "is a multiboot compliant image".
Updates can be made to the "is_multiboot_img" subroutine of gen_kvm_libvirt_xml

[Launchpad Janitor (janitor)]

This bug was fixed in the package eucalyptus - 2.0~bzr1218-0ubuntu1

---------------
eucalyptus (2.0~bzr1218-0ubuntu1) maverick; urgency=low

  [ Dave Walker (Daviey) ]
  * New upstream merge, r1218
  * debian/eucalyptus.conf:
    - Changed JVM_MEM to CLOUD_OPTS, as a standardised method.
    - Introduced new stub SC, adding ability to disable EBS and ISCSI.
    - Added to CC stub ability to disable tunnelling in multi-cluster deployments.
    - In NC section added various VIRTIO options with sane defaults.
    - Added hints for changing the resource allocation, making limiting and over
      provisioning easier to identify. (MAX_MEM, MAX_CORES & MAX_DISK).
  * debian/control:
    - eucalyptus-nc, Added Recommends libcrypt-openssl-(random,rsa,x509)-perl
    - eucalytpus-sc, Added Recommends tgt, open-iscsi
    - eucalyptus-java-common, Depend on libasm3-java rather than libasm2-java
  * debian/eucalyptus-nc.install: Install upstream isci perl scripts
    - /usr/share/eucalyptus/{connect,disconnect,get}_iscsitarget.pl
  * debian/eucalyptus-common.install: Install new upstream python tools:
    euca-{describe|(de)register}-walrus(es), euca-describe-properties
    euca-{add|delete|describe}-user(s), euca-get-credentials
    euca-{describe|(de)register}-cluster(s), euca-modify-property
    euca-{describe|(de)register}-storage-controller(s). (LP: #608773)
  * debian/patches/:
    - 07-local_support_euca_conf-in.patch: Refactored to reflect upstream.
    - 12-tools-euca_conf-8.patch: Dropped, applied upstream.
    - 13-tools_eucalyptus-conf-5.patch: Dropped, applied upstream.
    - 20-brute-force-webui.patch: Dropped, applied upstream.
  * The binary resulting jar's have been renamed from eucalyptus-*-main.jar
    to eucalyptus-*-2.0.0.jar:
    - debian/eucalyptus-cc.upstart
    - debian/eucalyptus-cloud.install
    - debian/eucalyptus-common.eucalyptus.upstart
    - debian/eucalyptus-java-common.install
    - debian/eucalyptus-network.upstart
    - debian/eucalyptus-sc.install
    - debian/eucalyptus-walrus.install

  [ Scott Moser ]
  * Add support for booting multiboot images from a floppy (LP: #611144)
 -- Dave Walker (Daviey) <email address hidden> Wed, 04 Aug 2010 06:36:06 +0100

[Andy Grimm (agrimm)]

This issue is now being tracked upstream at http://eucalyptus.atlassian.net/browse/EUCA-2723

Please watch that issue for further updates.