Launchpad Entry: server-maverick-cloud-images-sans-cloud
Contributors: Scott Moser
Packages affected: cloud-init
The UEC images contain a "ready-to-run" installation Ubuntu Server that supports running as a guest in an EC2 compatible environment. Making that image run under kvm would make it easier for someone to test or demo or use Ubuntu Server as a virtual machine.
Official Ubuntu Images produced for UEC and EC2 can now be run outside the cloud. The UEC images provide a ready to use installation of the Ubuntu Server. Now you can take advantage of this to quickly demo or test Ubuntu Server in a virtual machine without going through an ISO install.
The Ubuntu Desktop has 'Live CDs' readily available for quickly testing or demo-ing. Testdrive makes these even easier to use. The Ubuntu Server has no such thing. The UEC Images are basically a "already installed" version of the Ubuntu Server. If we can make the images easiliy run as a guest in a hypervisor (KVM) then the would provide an easy way to quickly test Ubuntu Server.
- Jane would like to test a daily build of Ubuntu Maverick to verify if a fix she put in is functional. She would like to verify the fix in a fresh install, and has a system that supports kvm.
- The primary intent of the UEC images is to function well in the EC2/UEC cloud. Running the images elsewhere is secondary and should not reduce function on UEC/EC2.
- Code will need to be added to the ec2-automated-build scripts to create metadata that can be consumed by tools (testdrive or libvirt) to launch the images locally.
cloud-init will have to be made to support a "bare" DataStore. Currently the only data store is EC2. If function without network is desired, the initial 'cloud-init' upstart job will have to be modified to run even when there is no eth0.
- Other cloud-init jobs will have to be made to handle lack of EC2 metadata service gracefully.
- Test that testdrive can launch a UEC image, and results in a system where the user can login locally at the kvm console. - Test that user can launch image through libvirt with same results as above - Test that user can launch image through manual kvm
TODO: This need not be added or completed until the specification is nearing beta.
EC2 and UEC expect input to be a partition image. KVM and other hypervisors expect input as a full disk image. These differences are largely at odds with each other. Non EC2 hypervisors would benefit from a traditional boot loader (ie grub) being installed inside the image itself, which would handle loading of the kernel. However, such a boot loader isn't going to work in EC2.
The current plan is reduce the difficulty of running a UEC image in non-EC2 environment by providing tools that easily prepare and launch the image. An alternative solution is to make 2 different downloads available. The second format would be ideal for kvm (possibly compressed qcow2 filesystem that could be directly ran). The negative affect of this is in storage on the server and possible confusion by users over which files should be downloaded.
BoF agenda and discussion
https://blueprints.launchpad.net/ubuntu/+spec/server-maverick-cloud-images-sans-cloud Running cloud images outside UEC or EC2 The UEC cloud images provide a canned Ubuntu Server instance. It is similar in that sense to the Desktop Live CDs. However, due to cloud-specific pieces, it is not very usable outside of EC2 or UEC. This session will discuss other ways which the cloud images could be run, or uses they might have. * within testdrive * within kvm == Whiteboard == Overall, we would like to be able to use these cloud images to provide a "live ubuntu server", for demo, development, or bug fix verification. The following is a non-exhaustive list of things we'd like for a user to be albe to do: * log in as a local user even without network * if network is present * provide ssh access * provide functional 'apt' * not require root access to run the image in kvm or qemu (ie, no loop back mounting of filesystem) EC2 and UEC prvide the "metadata service" and "user-data" that allow for the launcher of the instance to provide some customization data. Without that present, we will have to provide another mechanism thorough which that data can be passed. Some low maintainence options are kernel command line, secondary disk. During development of 10.04's cloud-init, I did some work at lp:~smoser/+junk/boothooks to aid in local booting of the images. This works around the following issues: - No local login is possible. When run in UEC/EC2 the images are completely locked down and only grant access to the public key of the user that launched the image. The root and ubuntu users have no password. - The image is a filesystem image, but expects to be booted as 'root=/dev/sda1'. /etc/fstab in the image has '/dev/sda1', causing mountall to wait forever for sda1, which would not ever be present. - images depend on the metadata service and will hang waiting for one to appear. The primary reason that is required is that in both UEC and EC2, the metadata service may not be present early in boot. Waiting for long periods of time is the only way to resolve that. - add login on serial console - enable password based login via ssh, and set local users password