Failsafe and manual management of kernels on EC2

On 10.10 and later, Ubuntu images use the Amazon provided pv-grub to load kernels that live inside the image. The selected kernel is controlled by /boot/grub/menu.lst. This makes it possible to install a new kernel via 'dpkg -i' or 'apt-get dist-upgrade' and then reboot into the new kernel.

The file /boot/grub/menu.lst is managed by grub-legacy-ec2 package. The program 'update-grub-legacy-ec2' is called on installation of Ubuntu kernels through files that are installed in /etc/kernel/postinst.d and /etc/kernel/postrm.d.

By default, as with other Ubuntu systems, the kernel with the highest revision will be the behavior will be automatically selected as the default, and selected on the next boot. Because EC2 images is read-only, you may want to manually manage your selected kernel. This can be done by modifying /boot/grub/menu.lst to use the grub "fallback" code.

I'll launch an instance of the current released maverick (ami-ccf405a5 in us-east-1 ubuntu-maverick-10.10-i386-server-20101225). Then, on the instance, create hard links to the default kernel and ramdisk so even on apt removal, they'll stick around, and then change /boot/grub/menu.lst to use those kernels.


sudo ln /boot/vmlinuz-$(uname -r) /boot/vmlinuz-failsafe
sudo ln /boot/initrd.img-$(uname -r) /boot/initrd.img-failsafe


Then, copy the existing entry in /boot/grub/menu.lst to a new entry above the automatic section. I've changed/added:


# You can specify 'saved' instead of a number. In this case, the default entry
# is the entry saved with the command 'savedefault'.
# WARNING: If you are using dmraid do not use 'savedefault' or your
# array will desync and will not let you boot your system.
default saved

...<snip>...

# Put static boot stanzas before and/or after AUTOMAGIC KERNEL LIST

# this is the failsafe kernel, it will be '0' as it is the first
# entry in this file
title Failsafe kernel
root (hd0)
kernel /boot/vmlinuz-failsafe root=LABEL=uec-rootfs ro console=hvc0 FAILSAFE
initrd /boot/initrd.img-failsafe
savedefault

title Ubuntu 10.10, kernel 2.6.35-24-virtual
root (hd0)
kernel /boot/vmlinuz-2.6.35-24-virtual root=LABEL=uec-rootfs ro console=hvc0 TEST-KERNEL
initrd /boot/initrd.img-2.6.35-24-virtual
savedefault 0


And then update grub to store that the first kernel is the 'saved', which for grub 1 (or 0.97) modifies /boot/grub/default.


sudo grub-set-default 0
sudo reboot


Now, a reboot will boot into the failsafe kernel (which we can verify by checking /proc/cmdline) and see 'FAILSAFE'. Then, to test our "TEST-KERNEL", run:


sudo grub-set-default 1
sudo reboot


After this reboot, the system come up into "TEST-KERNEL" (per /proc/cmdline) but /boot/grub/default will contain '0', indicating that on subsequent boot, the FAILSAFE will run. In this way, if your kernel failed to boot all the way up, you can then just issue:


euca-reboot-instances i-15b77779


And you'll boot back into the FAILSAFE kernel.

The above basically allows you to manually manage your kernels while letting grub-legacy-ec2 still write entries to /boot/grub/menu.lst.

I chose to use hardlinks for the 'failsafe' kernels, so that even on dpkg removal, the files would still exist. Because the 10.10 Ubuntu kernels have the EC2 network and disk drivers built in, you'll still be able to boot even after a dpkg removal of the failsafe kernel or an errant 'rm -Rf /lib/modules/2*'

Using euca2ools rather than ec2-api-tools with EC2

The Ubuntu UEC Images that Ubuntu produces on EC2 are in every way fully supported, "Official Ubuntu". As with other official releases, access to source code for security and maintenance reasons affects our decisions on what is included.

In the UEC images, the most notable packages left out are 'ec2-api-tools' and 'ec2-ami-tools'. I personally use the ec2-api-tools and ec2-ami-tools quite frequently and Amazon has done a great job with them. However, the license and lack of source code prevents them from being in Ubuntu 'main'.

Fortunately
a.) There are packages made available in the Ubuntu 'multiverse' component.
b.) The euca2ools package is installed by default and provides an almost drop in replacement for the ec2-api-tools and ec2-ami-tools.

I think that many users of EC2 aren't aware of the euca2ools, so I'd like to give some information on how to use them here.

The ec2-api-tools use the SOAP interface and thus use the "EC2_CERT" and "EC2_PRIVATE_KEY". The euca2ools sit on top of the excellent boto project. Boto uses the AWS REST api, which means authentication is done with your "Access Key" and "Secret Key". As a result, configuration is a little different. (Note, bundling images, you still need the EC2_CERT and EC2_PRIVATE_KEY for encryption/signing).

Configuration for euca2ools can be done via environment variables (EC2_URL, EC2_ACCESS_KEY, EC2_SECRET_KEY, EC2_CERT, EC2_PRIVATE_KEY, S3_URL, EUCALYPTUS_CERT) or via config file. I personally prefer the configuration file approach.

Here is my ~/.eucarc that is configured to operate with the EC2 us-east-1 region.

CRED_D=${HOME}/creds/aws-smoser
EC2_REGION="${EC2_REGION:-us-east-1}"
EC2_CERT=${CRED_D}/cert.pem
EC2_PRIVATE_KEY=${CRED_D}/pk.pem
EC2_ACCESS_KEY=ABCDEFGHIJKLMNOPQRST
EC2_SECRET_KEY=UVWXYZ0123456789abcdefghijklmnopqrstuvwx
EC2_USER_ID=950047163771
EUCALYPTUS_CERT=/etc/ec2/amitools/cert-ec2.pem
EC2_URL=https://ec2.${EC2_REGION}.amazonaws.com
S3_URL=https://s3.amazonaws.com:443


Things to note above:

• euca2ools sources the ~/.eucarc file with bash, and then reads out the values of EC2_REGION, EC2_CERT, EC2_PRIVATE_KEY, EC2_ACCESS_KEY, EC2_USER_ID, EC2_URL, S3_URL. This means that you use other bash functionality in the config file as I've done above with 'EC2_REGION'. This allows me to do something like:
  
EC2_REGION=us-west-1 euca-describe-images

  
• If there is no configuration file specified with '--config', then those values will be read from environment variables


• Amazon's public certificate from the ami tools is included with euca2ools in ubuntu, and located in /etc/ec2/amitools/cert-ec2.pem


• Many of the euca2ools commands will run significantly faster than the ec2-api-tools. The reason for slowness of the ec2-api-tools is their man java dependencies (please correct me if I'm wrong).
  
• Your ~/.eucarc file contains credentials and therefore it should be protected with filesystem permissions (ie 'chmod go-r ~/.eucarc').
  

Hopefully this will make it easier for you to use euca2ools with EC2 on Ubuntu.

Ubuntu Natty Narwhal Cluster Compute Instances

Some time ago, Amazon announced two new instance types aimed at high performance computing. The new types differ from Amazon's previous offerings in that

• They use Xen "hvm" (Hardware Virtualization Mode) rather than 'paravirtualization'
  
• Only priviledged accounts can create images of the 'hvm' virtualization-type.
  

The result is that there are very few public images for cluster compute nodes, and up until today, there were no Ubuntu images.

I'm happy to announce that you can now run Official Ubuntu images on cluster compute instance types. From today forward we will be publishing daily builds of Natty Narwhal builds.

These images are identical to the other Ubuntu images. For AMI ids, you can browse the list at http://uec-images.ubuntu.com/server/natty/current/, or use more machine friendly data at http://uec-images.ubuntu.com/query.

There is one known bug (bug 690286) that prevents you from using ephemeral storage on the CC nodes.

If you've got a couple dollars burning a whole in your pocket, you can try one out with:

qurl="http://uec-images.ubuntu.com/query/"
ami_id=$(curl --silent "${qurl}/natty/server/daily.current.txt" |
    awk '-F\t' '$11 == "hvm" && $7 == "us-east-1" { print $8 }')
ec2-run-instances --key mykey --instance-type cc1.4xlarge "${ami_id}"

lvm resizing is easy

I have a local mirror of the ubuntu archive, using some scripts based on the Ubuntu Wiki. When I set up "/archive" on my local mirror, I used lvm. The reason for that was primarily so that I could use sbuild with lvm.

Since then, 2 things have happened:

• sbuild has gained the ability to use aufs rather than LVM snapshots. The solution is much lighter weight, and doesn't require some lvm space sitting around waiting to be used.
• The ubuntu archive has grown in size from ~ 250G to ~ 400G right now.

So, it was time for me to resize the filesystem that had my archive up to accommodate. For my own record, and possibly others, I thought I'd share what I did.


$ sudo pvscan
PV /dev/sdb VG smoser-vol1 lvm2 [931.51 GiB / 315.57 GiB free]
PV /dev/sda1 VG nelson lvm2 [148.77 GiB / 44.00 MiB free]
$ sudo lvscan
ACTIVE '/dev/smoser-vol1/smlv0' [585.94 GiB] inherit
ACTIVE '/dev/smoser-vol1/hardy_chroot-i386' [5.00 GiB] inherit
ACTIVE '/dev/smoser-vol1/lucid_chroot-i386' [5.00 GiB] inherit
ACTIVE '/dev/smoser-vol1/karmic_chroot-i386' [5.00 GiB] inherit
ACTIVE '/dev/smoser-vol1/karmic_chroot-amd64' [5.00 GiB] inherit
ACTIVE '/dev/smoser-vol1/lucid_chroot-amd64' [5.00 GiB] inherit
ACTIVE '/dev/smoser-vol1/hardy_chroot-amd64' [5.00 GiB] inherit
ACTIVE '/dev/nelson/root' [142.65 GiB] inherit
ACTIVE '/dev/nelson/swap_1' [6.07 GiB] inherit


I had 2 physical volumes, sdb and sda1. 'sdb' had my old sbuild snapshots on it, and also some free space. So, I deleted sbuild snapshots with:


$ sudo lvremove /dev/smoser-vol1/hardy_chroot-i386 \
/dev/smoser-vol1/lucid_chroot-i386 /dev/smoser-vol1/karmic_chroot-i386 \
/dev/smoser-vol1/karmic_chroot-amd64 /dev/smoser-vol1/lucid_chroot-amd64 \
/dev/smoser-vol1/hardy_chroot-amd64


Then, resized the 'smlv0' volume that had my '/archive' on it up to the largest that I could on that physical volume:


$ sudo vgdisplay smoser-vol1
VG Name smoser-vol1
System ID
Format lvm2
<snip>
VG Size 931.51 GiB
...
$ sudo lvresize /dev/smoser-vol1/smlv0 --size 931.51G
Rounding up size to full physical extent 931.51 GiB
Extending logical volume smlv0 to 931.51 GiB
Logical volume smlv0 successfully resized


Then, just resize the ext4 filesystem on that volume:

$ grep archive /proc/mounts
/dev/mapper/smoser--vol1-smlv0 /archive ext4 rw,relatime,barrier=1,data=ordered 0 0
$ sudo resize2fs /dev/mapper/smoser--vol1-smlv0
resize2fs 1.41.11 (14-Mar-2010)
Filesystem at /dev/mapper/smoser--vol1-smlv0 is mounted on /archive; on-line resizing required
old desc_blocks = 37, new_desc_blocks = 59
Performing an on-line resize of /dev/mapper/smoser--vol1-smlv0 to 244190208 (4k) blocks.

The filesystem on /dev/mapper/smoser--vol1-smlv0 is now 244190208 blocks long.


That last operation did take probably 30 minutes, but in the end, I now have:


$ df -h /archive/
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/smoser--vol1-smlv0
917G 544G 327G 63% /archive


Using Ubuntu Images on AWS "Free Tier"

[Update 2011-01-20]

There are now official Ubuntu AMIs that fit into the Free Tier disk requirements. You can get a list of the AMIs for 10.04 or 10.10.

This article is still useful as documentation, but is not necessary if you only want to use Ubuntu on Amazon's Free Tier.

Amazon AWS recently announced an AWS Free Usage Tier. The summary of which is that new AWS customers can run a t1.micro instance 24x7 for the next year and pay nothing (or at least very little).

There are various restrictions on what you get for free, but the most interesting to the Ubuntu images is:

10 GB of Amazon Elastic Block Storage, plus 1 million I/Os, 1 GB of snapshot storage, 10,000 snapshot Get Requests and 1,000 snapshot Put Requests*

The Official Ubuntu Images have a 15GB root filesystem. What that means is if you're using any of our official images (10.04, 10.10), then you will be charged for 5GB of provisioned storage per month. In the us-east-1 region that would be $0.50/month. In other regions, that would be $0.55/month.

This issue has been raised on the AWS Discussion Forums, but it seems like Amazon is not willing to budge.

Similarly, bug 670161 was opened requesting "10GB root partition for EBS boot AMIs on EC2". If you're interested in following this discussion, subscribe yourself to that bug. I will make sure that it is kept up to date.

I don't want to comment right now on whether or not we will release future EBS root AMIs of 10.04 and and 10.10 with a 10GB filesystem instead of a 15G filesystem. What I do want to discuss is how you can create your own AMI that has a 10G (or smaller) root filesystem, which will perform otherwise identically to the official images.

If you want to use Ubuntu on the Amazon Free Tier *right now*, then you can follow these instructions, which assume you have the ec2-api-tools correctly configured on your laptop. And you have a keypair named "mykey" available in the target region.

In the code (shell prompt) snippits below, '$' prompt indicates command run on my laptop. '%' prompt indicates command run on the ec2 instance. lines beginning with a '#' are comments.

Launch an instance to work with:

# us-east-1 ami-548c783d canonical ebs/ubuntu-maverick-10.10-amd64-server-20101007.1
$ ec2-run-instances --region us-east-1 --instance-type t1.micro \
--key mykey ami-548c783d
$ iid=i-1855ea75
$ zone=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $12 }' iid=${iid} )
$ echo ${zone}
us-east-1d
$ host=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $4 }' iid=${iid} )
$ echo ${host}
ec2-174-129-61-12.compute-1.amazonaws.com


create a volume in correct zone of the desired size to attach to the instance. Change '10' to '5' if you wanted a 5GB root filesystem.

$ ec2-create-volume --size 10 --availability-zone ${zone}
$ vol=vol-c64d55af
$ ec2-attach-volume --instance ${iid} --device /dev/sdh ${vol}


Then, ssh to ubuntu@${host}, and download the uec reference image and extract it. Below, I've downloaded the i386 image for maverick. You could browse through at http://uec-images.ubuntu.com/releases/10.10/release/ and find an amd64 image or a 10.04 base image.

% sudo chown ubuntu:ubuntu /mnt
% cd /mnt
% url=http://uec-images.ubuntu.com/releases/10.10/release/ubuntu-10.10-server-uec-i386.tar.gz
% tarball=${url##*/}
% wget ${url} -O ${tarball}
% tar -Sxvzf ${tarball}
maverick-server-uec-i386.img
maverick-server-uec-i386-vmlinuz-virtual
maverick-server-uec-i386-loader
maverick-server-uec-i386-floppy
README.files
% img=maverick-server-uec-i386.img
% mkdir src target


create target filesystem, mount the attached volume, and copy source filesystem contents to target filesystem using rsync.

% sudo mount -o loop,ro ${img} /mnt/src
% sudo mkfs.ext4 -L uec-rootfs /dev/sdh
% sudo mount /dev/sdh /mnt/target
# the rsync could take quite a while. for me it took 22 seconds.
% sudo rsync -aXHAS /mnt/src/ /mnt/target
% sudo umount /mnt/target
% sudo umount /mnt/src


Now, back on the laptop, snapshot the volume.

$ ec2-create-snapshot ${vol}
$ snap=snap-b97dfdd3
# now you have to wait for snapshot to be 'completed'
$ ec2-describe-snapshots ${snap}
SNAPSHOT snap-b97dfdd3 vol-c64d55af completed 2010-11-03T17:31:52+0000 100% 950047163771 10


Turn the contents of that volume into an AMI. Note, you must set 'arch', 'rel', and 'region' correctly. Then, we use that information to get the aki associated with the most recent released Ubuntu image.


$ rel=maverick; region=us-east-1; arch=i386; # arch=amd64
$ [ $arch = amd64 ] && xarch=x86_64 || xarch=${arch}
$ qurl=http://uec-images.ubuntu.com/query/${rel}/server/released.current.txt
$ aki=$(curl --silent "${qurl}" |
awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' \
arch=$arch region=$region )
$ echo ${aki}
aki-407d9529
$ ec2-register --snapshot ${snap} \
--architecture=${xarch} --kernel=${aki} \
--name "my-ubuntu-${rel}" --description "my-ubuntu-${rel}"
IMAGE ami-4483742d
$ ami=ami-4483742d


Clean up your instance and volume

$ ec2-detach-volume ${vol}
$ ec2-terminate-instances ${iid}
$ ec2-delete-volume ${vol}


And now run your instance

$ ec2-run-instances --instance-type t1.micro ${ami}
$ ssh ubuntu@
% sudo apt-get update && sudo apt-get dist-upgrade
# if you got a new kernel (linux-virtual package), then you will
# need to reboot
% sudo reboot


Now, your newly created image has filesystem contents that are identical to those of the official Ubuntu images, but with a 10G filesystem.

Once you've launched your image, you can actually clean up the snapshot and the AMI id that you launched. To do that:

ec2-deregister ${ami}
ec2-delete-snapshot ${snap}


The cost of the above operations will probably be on the order of pennies, and will remove the costs you would have incurred due to having 15G root volume.

create image with XFS root filesystem from UEC Images

A post was made to the ec2ubuntu google group asking if Ubuntu had any plans to create images XFS root filesystems.

The Official Ubuntu Images for 10.04 LTS (lucid) and prior have an ext3 root filesystem. For Ubuntu 10.10 (maverick) and the development builds of 11.04, the filesystem is ext4.

The selection of ext3 or ext4 is because ext4 is the filesystem selected by default on an Ubuntu install from CD or DVD. This selection is carried over to our Ubuntu images for UEC or EC2. The 10.04 images really should have been ext4, but the change didn't get in for that release.

Ubuntu fully supports the XFS filesystem, it simply wasn't chosen as the default. The -virtual kernel has filesystem support available as a module, and the xfsprogs package is in the main archive.

So, just as you can get full support for the Ubuntu images using ext4, you can get full support from Ubuntu (and paid support from Canonical) by using xfs as your root filesystem. You will simply have to create your own images.

Luckily, due primarily due to the fact that the Ubuntu images are downloadable at http://uec-images.ubuntu.com, the process for creating a XFS based ebs image is trivial.

In the code (shell prompt) snippits below, '$' prompt indicates command run on my laptop. '%' prompt indicates command run on the ec2 instance. lines beginning with a '#' are comments.

Launch an instance to work with:

# us-east-1 ami-688c7801 canonical ubuntu-maverick-10.10-amd64-server-20101007.1
$ ec2-run-instances --region us-east-1 --instance-type m1.large \
--key mykey ami-688c7801
$ iid=i-bcc679d1
$ zone=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $12 }' iid=${iid} )
$ echo ${zone}
us-east-1d
$ host=$(ec2-describe-instances $iid |
awk '-F\t' '$2 == iid { print $4 }' iid=${iid} )
$ echo ${host}
ec2-174-129-61-12.compute-1.amazonaws.com



create a volume in correct zone of the desired size to attach to the instance.

$ ec2-create-volume --size 10 --availability-zone ${zone}
$ vol=vol-c64d55af
$ ec2-attach-volume --instance ${iid} --device /dev/sdh ${vol}


Then, ssh to ubuntu@${host}, and download the uec reference image, extract, and get necessary packages:

% sudo chown ubuntu:ubuntu /mnt
% cd /mnt
% url=http://uec-images.ubuntu.com/releases/10.10/release/ubuntu-10.10-server-uec-i386.tar.gz
% tarball=${url##*/}
% wget ${url} -O ${tarball}
% tar -Sxvzf ${tarball}
maverick-server-uec-i386.img
maverick-server-uec-i386-vmlinuz-virtual
maverick-server-uec-i386-loader
maverick-server-uec-i386-floppy
README.files
% img=maverick-server-uec-i386.img
% mkdir src target
% sudo apt-get install xfsprogs


create target filesystem, mount the attached volume, and copy source filesystem contents to target filesystem using rsync.

% sudo mount -o loop,ro ${img} /mnt/src
% sudo mkfs.xfs -L uec-rootfs /dev/sdh
% sudo mount /dev/sdh /mnt/target
% sudo rsync -aXHAS /mnt/src/ /mnt/target
% sudo umount /mnt/target
% sudo umount /mnt/src


Above, you could have mounted /proc and /sys into /mnt/target, chrooted into it and done a dist-upgrade. I left that out for simplicity.

Now, back on the laptop, snapshot the volume.

$ ec2-create-snapshot ${vol}
$ snap=snap-b97dfdd3
# now you have to wait for snapshot to be 'completed'
$ ec2-describe-snapshots ${snap}
SNAPSHOT snap-b97dfdd3 vol-c64d55af completed 2010-11-03T17:31:52+0000 100% 950047163771 10


Turn the contents of that volume into an AMI. Note, you must set 'arch', 'rel', and 'region' correctly. Then, we use that information to get the aki associated with the most recent released Ubuntu image.


$ rel=maverick; region=us-east-1; arch=i386; # arch=amd64
$ [ $arch = amd64 ] && xarch=x86_64 || xarch=${arch}
$ [ $arch = amd64 ] && blkdev=/dev/sdb || blkdev=/dev/sda2
$ qurl=http://uec-images.ubuntu.com/query/${rel}/server/released.current.txt
$ aki=$(curl --silent "${qurl}" |
awk '-F\t' '$5 == "ebs" && $6 == arch && $7 == region { print $9 }' \
arch=$arch region=$region )
$ echo ${aki}
aki-407d9529
$ ec2-register --snapshot ${snap} \
--architecture=${xarch} --kernel=${aki} \
--block-device-mapping ${blkdev}=ephemeral0 \
--name "my-${rel}-xfs-root" --description "my-${rel}-xfs-description"
IMAGE ami-4483742d
$ ami=ami-4483742d


Clean up your instance and volume

$ ec2-detach-volume ${vol}
$ ec2-terminate-instances ${iid}
$ ec2-delete-volume ${vol}


And now run your instance

$ ec2-run-instances --instance-type t1.micro ${ami}


ssh to your instance, verify that it is in fact xfs:

% grep uec-rootfs /proc/mounts
/dev/disk/by-label/uec-rootfs / xfs rw,relatime,attr2,nobarrier,noquota 0 0


Now, your newly created image has filesystem contents that are identical to those of the official Ubuntu images.

Some notes on the above:

• Many people believe that transition to btrfs as the default filesytem is inevitable, possibly even for the 12.04 LTS release. Doing this on EC2 would require that amazon release btrfs support in a pv-grub kernel.
• Outside of creating a 'xfs' filesystem, the steps above are very generic "create a custom EBS root image" instructions. In fact, the process outlined above is used for the actual publishing of ebs images via the ec2-publishing-scripts (see ec2-image2ebs)
.
• The process above will work using the maverick based images. Lucid images are not likely to work out of the box because they do not boot with a ramdisk. Where maverick images use pv-grub to load the kernel and ramdisk from inside the image, Lucid kernels are loaded by xen directly and Canonical did not publish ramdisks for the lucid release.

UDS-N Call for participation

The Ubuntu Developer Summit (UDS) is the event in which the Ubuntu community discusses and plans the upcoming Ubuntu release. UDS Natty begins Monday, October 25th (this monday) outside of Orlando, FL, USA. If you're in the Orlando area, this event is free, and open to anyone.

If you've not yet made plans to attend physically, then its unlikely that you'll be present in the rooms. However, the Canonical IS does an outstanding job of making remote participation possible. For more information, on how you can participate remotely, read the Remote Participation document. In short, you join an IRC channel, listen to a live high quality audio stream from the room, and can see edits to a live gobby document.

The comprehensive list of all sessions is available through the summit schedule, or a filtered list of only the 'Cloud track'.

Some of the sessions that I personally am interested (ok, interested *and* leading) in are:

• cloud-server-n-cloud-images: Here we'll discuss how we can make the Ubuntu Images on EC2 or UEC better. If you've used them, then we're interested in your feedback.
• cloud-server-n-image-rebundle: Here we'll discuss possible improvements in the rebundling process. Ie, how can you take one of the Ubuntu images, and customize it and turn it into your own AMI. This is a common operation, and unfortunately, one that has some sticking points. If you have other ideas for "cloud utilities" this is the place to bring them up.
• cloud-server-n-desktop-images: Ubuntu has made desktop images available on ec2 in a "tech preview" like manner for 2 releases. We've not fully supported these images, but a version of the cloud images with a remote-desktop interface is a common request. If you want to see what it might look like, try out the free Edubuntu demo using NX
• cloud-server-n-cloud-init: Here we'll discuss improvements to cloud-init or cloud-config. If you've customized images via user-data, then you've used cloud-init. How can we make it better ?
• cloud-server-n-ubuntu-trial: We threw together awstrial fairly quickly, and with the 10.10 release, we allowed anyone interested to Try Ubuntu Free. We got a great response and we see lots of ways this can be used. Come and let us know what you think

There are loads of other interesting sessions. If 'Server' or 'Cloud' isn't your thing, there are other tracks that might peek your interest.