eucalyptus should support booting multiboot image
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Eucalyptus |
New
|
Wishlist
|
Dmitrii Zagorodnov | ||
eucalyptus (Ubuntu) |
Fix Released
|
Wishlist
|
Scott Moser |
Bug Description
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>
</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://
ProblemType: Bug
DistroRelease: Ubuntu 10.10
Package: eucalyptus-nc 2.0~bzr1211-
ProcVersionSign
Uname: Linux 2.6.32-305-ec2 i686
Architecture: i386
Date: Thu Jul 29 03:15:18 2010
Ec2AMI: ami-e930db80
Ec2AMIManifest: ubuntu-
Ec2Availability
Ec2InstanceType: m1.small
Ec2Kernel: aki-407d9529
Ec2Ramdisk: unavailable
ProcEnviron:
PATH=(custom, user)
LANG=en_US.UTF-8
SHELL=/bin/bash
SourcePackage: eucalyptus
Related branches
- Dave Walker (community): Approve
- Ubuntu branches: Pending requested
-
Diff: 2160 lines (+1986/-9)15 files modified.pc/22-uec-multiboot-kvm.patch/node/handlers.c (+1227/-0)
.pc/22-uec-multiboot-kvm.patch/tools/Makefile (+71/-0)
.pc/22-uec-multiboot-kvm.patch/tools/gen_kvm_libvirt_xml (+165/-0)
.pc/22-uec-multiboot-kvm.patch/util/wrappers.conf (+51/-0)
.pc/applied-patches (+1/-0)
debian/changelog (+6/-0)
debian/control (+4/-1)
debian/eucalyptus-nc.install (+1/-0)
debian/patches/22-uec-multiboot-kvm.patch (+292/-0)
debian/patches/series (+1/-0)
node/handlers.c (+4/-0)
tools/Makefile (+2/-0)
tools/gen_kvm_libvirt_xml (+47/-8)
tools/mk-mb-loader (+113/-0)
util/wrappers.conf (+1/-0)
Changed in eucalyptus (Ubuntu): | |
importance: | Undecided → Wishlist |
Changed in eucalyptus: | |
assignee: | nobody → Dmitrii Zagorodnov (dmitrii) |
importance: | Undecided → Wishlist |
@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