RawDiskImages

Raw Disk Images (VM Images without a kernel and ramdisk)

Background

Paravirtualized Xen relied on a special kernel, and cleverly was able to implement virtualization without full hardware support. Since then, full hardware support in the chip has become much more widespread, and the complexity of a separate ramdisk and kernel image is now technically unnecessary.

This blueprint is to discuss the tweaks to enable this.

Nasa may have some ongoing business requirement for kernels/ramdisks ?

Logic for booting without kernel/ramdisk

Currently, if no kernel/ramdisk is specified when the image is registered, and no kernel/ramdisk is specified when the instance is launched it will launch without a kernel/ramdisk. This way it's still compatible with the euca-tools.

vish: The logic for booting without kernel if it isn't specified may need to be changed. We may need a flag to allow booting without specifying a kernel, perhaps global and/or per-image in the image store.

justinsb: Yes, this was just a hack so that I could get it to work with the euca- tools. Any ideas on a better side-channel to use with the euca-tools (until we get our own)? Right now it's not too bad... if you don't specify a kernel at either the image registration or the instance launching, it'll presume there's no kernel and so it's a whole disk image.

justinsb: Is there a "requirements" problem with the way it's done now, or is it just that it's a bit of a hack?

Fixing up of disk images

Currently, before the disk is booted, it is mounted (as a loopback device, meaning the host must be aware of the guest FS), and then files are injected into it. Currently it's a bit of a hard-coded mess!

Also, some of the fixes that are done probably don't belong here - some of them are really mistakes in image building.

vish: I pushed a fix called mac-fix that stops persistent rules from being set by udev. Probably will make that remove-udev rules param in your raw- disk-images obsolete.

justinsb: Thanks... I think the remove-udev rules bit was probably more because I made a mistake bundling the image (leaving the old rules file), and found it much easier to fix this way. I've been advised I should simply have deleted the network udev rule file as part of image construction.

justinsb: This is therefore probably part of a much larger debate about what should be done in the image, and what by the 'launch VM' stage. The launch VM stage is convenient for me right now, but it won't cope with other OSes or probably even other distros.

justinsb: One possibility is to have a script that can fix common mistakes, that could be run just before image uploading. This could even do really sneaky stuff, like figuring out the exact byte offsets to change so that we can inject data into filesystems that we don't really understand (e.g. Windows?)

justinsb: If you agree, I might move some of my more questionable functionality into a new script. For instance, I don't really think that module loading necessarily belongs in there; it's just me fixing up my own mistakes. But others will make the same mistakes, so it does need to be easy.

vish: Also, I hacked in the network injection really quickly. I think the inject code should take an arbitrary list of dictionaries representing the file location, owner and group, and data. Then you could pass whatever is needed in without adding to the list of parameters

justinsb: I agree that I've probably pushed that function to its limits in terms of number of parameters :-)

justinsb: What isn't clear to me is whether this OS/distro-specific knowledge should be exposed beyond the disk injection function. Maybe in an ideal world this mapping would be provided as part of the image upload. Any auto-detection code is likely to get messy fast, so it makes sense to contain that mess in a single class / group of classes.

---