Eucalyptus runs images without ramdisk with a default ramdisk

[Dustin Kirkland ]

Binary package hint: cloud-utils

$ TIMESTAMP=$(date +%Y%m%d%H%M%S)
$ BUCKET_IMAGE="i-$TIMESTAMP"
$ uec-publish-tarball ./lucid-server-uec-amd64
lucid-server-uec-amd64.img lucid-server-uec-amd64.tar.gz lucid-server-uec-amd64-vmlinuz-virtual
ubuntu@aussie:~$ uec-publish-tarball ./lucid-server-uec-amd64.tar.gz $BUCKET_IMAGE
Mon Feb 22 13:47:25 CST 2010: ====== extracting image ======
Warning: no ramdisk found, assuming '--ramdisk none'
kernel : lucid-server-uec-amd64-vmlinuz-virtual
ramdisk: none
image : lucid-server-uec-amd64.img
Mon Feb 22 13:47:34 CST 2010: ====== bundle/upload kernel ======
Mon Feb 22 13:47:44 CST 2010: ====== done ======
emi="emi-C78B14AA"; eri="none"; eki="eki-073719A9";
cleaning up /tmp/uec-publish-tarball.jU1PKD

Looks like image should work right?

$ euca-run-instances emi-C78B14AA -k mykey -t c1.medium
RESERVATION r-3D1E080B admin admin-default
INSTANCE i-4A070989 emi-C78B14AA 0.0.0.0 0.0.0.0 pending mykey 2010-02-22T20:14:49.288Z eki-073719A9 eri-092119A6

$ euca-describe-instances | grep i-4A070989

INSTANCE i-4A070989 emi-C78B14AA 10.1.1.106 172.19.1.8 shutting-down mykey 0 c1.medium
2010-02-22T20:14:49.288Z cluster1 eki-073719A9 eri-092119A6
...
INSTANCE i-4A070989 emi-C78B14AA 172.19.1.8 172.19.1.8 terminated mykey 0 c1.medium
2010-02-22T20:14:49.288Z cluster1 eki-073719A9 eri-092119A6

[Dustin Kirkland  (kirkland)]

Attaching output of

$ grep i-4A070989 /var/log/eucalyptus/*log > /tmp/i-4A070989.log

[Dustin Kirkland  (kirkland)]

Note that the following steps worked just fine, from https://help.ubuntu.com/community/UEC/BundlingImages:

ubuntu@aussie:~$ TIMESTAMP=$(date +%Y%m%d%H%M%S)
ubuntu@aussie:~$ RELEASE=lucid
ubuntu@aussie:~$ ARCH=amd64 # Or this might be i386
ubuntu@aussie:~$ [ $ARCH = "amd64" ] && IARCH=x86_64 || IARCH=i386
ubuntu@aussie:~$ UEC_IMG=$RELEASE-server-uec-$ARCH
ubuntu@aussie:~$ URL=http://uec-images.ubuntu.com/$RELEASE/current/
ubuntu@aussie:~$ [ ! -e $UEC_IMG.tar.gz ] && wget $URL/$UEC_IMG.tar.gz # This may take a bit, depending on your connectivity
ubuntu@aussie:~$ [ ! -e $UEC_IMG.img ] && tar -S -xzf $UEC_IMG.tar.gz
ubuntu@aussie:~$ BUCKET_KERNEL="k-$TIMESTAMP"
ubuntu@aussie:~$ UEC_KERNEL=$UEC_IMG-vmlinuz-virtual
ubuntu@aussie:~$ euca-bundle-image -i $UEC_KERNEL -r $IARCH --kernel true
x86_64
Checking image
Tarring image
Encrypting image
Splitting image...
Part: lucid-server-uec-amd64-vmlinuz-virtual.part.0
Generating manifest /tmp/lucid-server-uec-amd64-vmlinuz-virtual.manifest.xml
ubuntu@aussie:~$ euca-upload-bundle -b $BUCKET_KERNEL -m /tmp/$UEC_KERNEL.manifest.xml
Checking bucket: k-20100222135250
Creating bucket: k-20100222135250
Uploading manifest file
Uploading part: lucid-server-uec-amd64-vmlinuz-virtual.part.0
Uploaded image as k-20100222135250/lucid-server-uec-amd64-vmlinuz-virtual.manifest.xml
ubuntu@aussie:~$ EKI=$(euca-register $BUCKET_KERNEL/$UEC_KERNEL.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EKI
eki-07D419B5
ubuntu@aussie:~$ ls -alF $UEC_KERNEL
-rw-r--r-- 1 ubuntu ubuntu 4182784 2010-02-21 20:03 lucid-server-uec-amd64-vmlinuz-virtual
ubuntu@aussie:~$ BUCKET_IMAGE="i-$TIMESTAMP"
ubuntu@aussie:~$ UEC_IMG=$RELEASE-server-uec-$ARCH
ubuntu@aussie:~$ euca-bundle-image -i $UEC_IMG.img -r $IARCH --kernel $EKI
x86_64
Checking image
Tarring image
Encrypting image
Splitting image...
Part: lucid-server-uec-amd64.img.part.0
Part: lucid-server-uec-amd64.img.part.1
Part: lucid-server-uec-amd64.img.part.2
Part: lucid-server-uec-amd64.img.part.3
Part: lucid-server-uec-amd64.img.part.4
Part: lucid-server-uec-amd64.img.part.5
Part: lucid-server-uec-amd64.img.part.6
Part: lucid-server-uec-amd64.img.part.7
Part: lucid-server-uec-amd64.img.part.8
Part: lucid-server-uec-amd64.img.part.9
Part: lucid-server-uec-amd64.img.part.10
Part: lucid-server-uec-amd64.img.part.11
Part: lucid-server-uec-amd64.img.part.12
Part: lucid-server-uec-amd64.img.part.13
Part: lucid-server-uec-amd64.img.part.14
Part: lucid-server-uec-amd64.img.part.15
Part: lucid-server-uec-amd64.img.part.16
Part: lucid-server-uec-amd64.img.part.17
Part: lucid-server-uec-amd64.img.part.18
Part: lucid-server-uec-amd64.img.part.19
Generating manifest /tmp/lucid-server-uec-amd64.img.manifest.xml
EMI=$(euca-register $BUCKET_IMAGE/$UEC_IMG.img.manifest.xml | grep "^IMAGE" | awk '{print $2}') && echo $EMI
emi-C73F14A0

ubuntu@aussie:~$ euca-run-instances emi-C73F14A0 -k mykey -t c1.medium
RESERVATION r-30FF056D admin admin-default
INSTANCE i-3F8E0754 emi-C73F14A0 0.0.0.0 0.0.0.0 pending mykey 2010-02-22T20:20:14.956Z eki-07D419B5 eri-092119A6

ubuntu@aussie:~$ euca-describe-instances | grep i-3F8E0754
INSTANCE i-3F8E0754 e...

[Scott Moser (smoser)]

@Dustin,
is this a dupe of bug 522292

make sure you have current cloud-utils

[Thierry Carrez (ttx)]

I can confirm this issue with cloud-utils 0.5-0ubuntu1

The image registered through uec-register-tarball boots OK but hangs on metadata retrieval.
Looking at the eucalyptus side of things, we see that eucalyptus fails to serve "ramdisk-id".

It seems that the way uec-register-tarball registers ramdisks fails in UEC (makes it believe there is a ramdisk, or something).

[Scott Moser (smoser)]

Ok. So I was looking into this more, suspecting that uec-publish-tarball was in fact, buggy.

However, it looks like the bug is in Eucalyptus is buggy in its use of images that are registered without a ramdisk.

If you register image A with a ramdisk, and then register image B without a ramdisk, and start instance B, then it will be booted with the ramdisk registered with image A.

[Scott Moser (smoser)]

I've opened a track against Eucalpytus based on what Dustin and I found out today.

As far as I can tell, there is no problem with uec-publish-tarball. The reason it appeared to be buggy is that it would correctly register a ramdisk-less image. The boot of that image would hang in boto's attempt to crawl the metadata service (bug 526805).

Then, the user would register an image with a ramdisk, and the default ramdisk would get set (see https://${cloud_controller}:8443/#conf -> Configuration - > Default Ramdisk ). When an image was subsequently booted, it would get the default ramdisk and boot fine. However, it would have booted with errors like those seen in bug 525994 if the default ramdisk was for a kernel other than the current one.

[Dustin Kirkland  (kirkland)]

Chris, any progress here?

This is causing a few problems here right now...

[chris grzegorczyk (chris-grze)]

------------------------------------------------------------
revno: 1204
committer: decker <decker@personal-army>
branch nick: 1.6.2
timestamp: Fri 2010-03-05 01:05:00 -0800
message:
  fix LP: #525989
------------------------------------------------------------

[Launchpad Janitor (janitor)]

This bug was fixed in the package eucalyptus - 1.6.2-0ubuntu10

---------------
eucalyptus (1.6.2-0ubuntu10) lucid; urgency=low

  * Cherry-pick merge from upstream 1.6.2 from revision 1199 to 1206,
    affecting:
    clc/modules/cluster-manager/src/main/java/edu/ucsb/eucalyptus/cloud/cluster/ConsoleOutputCallback.java,
    clc/modules/cluster-manager/src/main/java/edu/ucsb/eucalyptus/cloud/cluster/VmInstance.java,
    clc/modules/image-manager/src/main/java/edu/ucsb/eucalyptus/cloud/ws/ImageManager.java,
    clc/modules/image-manager/src/main/java/edu/ucsb/eucalyptus/cloud/ws/VolumeManager.java,
    clc/modules/storage-controller/src/main/java/edu/ucsb/eucalyptus/storage/LVM2Manager.java,
    tools/euca_conf.in
  * This merge is expected to fix:
    - LP: #526506 - fix volume attach to /dev/sda
    - LP: #525989 - improve handling of non-ramdisk images
    - LP: #531536 - handle get-console-output better
 -- Dustin Kirkland <email address hidden> Fri, 05 Mar 2010 09:30:29 -0600