Monday, August 29, 2011

RFC: anyone using vmdk or ovf files from cloud-images?

Friday I posted the following on ec2ubuntu and ubuntu-cloud mailing lists. I'm posting here in an effort to reach a larger audience.

If you are using the OVF files or VMDK files, please respond.

Date: Fri, 26 Aug 2011 16:34:41
From: Scott Moser
Subject: Anyone using the .ovf and/or .vmdk files on cloud-images?

Hey all,

   Is anyone using the .vmdk or .ovf files on [1] ?

   In the 11.04 cycle, I started building .ovf files with corresponding
.vmdk images.  The goal of this was to make Ubuntu available for use via
software that supported importing OVF.
   I chose to to create the disk as VMDK formated images rather than a
more open-source friendly format such as qcow.   The OVF file and
associated disk image is consumable by both vmware tools and by
VirtualBox.  There are no OVF consumers that I'm aware of that would
function with a qcow (or even 'raw') disk image.  I feel compelled to also
mention that this format of vmdk (compressed) is not supported by qemu-img
or kvm.
   Since having an OVF that could not be used by any software is not
significantly more useful than not having an OVF, we went with vmdk.

   Largely prompted by the interest in providing a download format that is
ideal for OpenStack users [2], I am re-considering my decision.  I would
like to avoid adding another full disk image format to the output of the
build scripts.  As a result I'm thinking about replacing the .vmdk images
with compressed qcow images and updating the OVF files to reference those.

   The reason behind not wanting to just add yet another deliverable is
that more downloads are confusing, and disk space is not necessarily free.
If I can drop a deliverable not used by anyone, then I'd like to do that.

   So, would anyone object to the removal of .vmdk files from
cloud-images?  Is anyone using these that could not just as easily use
qcow2 formated images?



Tuesday, August 9, 2011

Amazon issues with EBS affect Ubuntu images in the EU-WEST region

Note: This blog post has been updated in-place.

We have received information from Amazon that the EBS snapshots for our released 10.04 images from 20110719 were not affected (ami-5c417128 and ami-52417126). It seems that an api issue incorrectly marked them as such. It was an error in our logic that associated snapshot-ids with amis that gave us the incorrect output. The only Ubuntu images that were affected were old daily builds and milestone releases. If you are interested in reading the original message, please do so on the Ubuntu cloud-announce mailing list archives.

We received this morning an automated email[1] from Amazon informing us of possible loss of data in EBS snapshots on the EU-WEST-1 region. Our engineering team immediately started an assessment of the damages this might have caused to the EBS images that we publish for our users. We are working with Amazon to re-mediate customer impact and prevent any future outages.

A number of non-current daily build and old alpha or beta images have been affected, but we hope that no one would have been using these images for production use; we are not planning corrective actions for these images. You can see the full list of AMIs affected at

To have this type of announcements sent to your email directly, please subscribe to our ubuntu-cloud-announce mailing list at

Our support services are available to help customers of the Ubuntu Advantage Cloud Guest program. Details about this program can be found at

[1] Email received from Amazon on Aug 9 2011 at 9:11 UTC


We've discovered an error in the Amazon EBS software that cleans up unused snapshots. This has affected at least one of your snapshots in the EU-West Region.

During a recent run of this EBS software in the EU-West Region, one or more blocks in a number of EBS snapshots were incorrectly deleted. The root cause was a software error that caused the snapshot references to a subset of blocks to be missed during the reference counting process. This process compares the blocks scheduled for deletion to the blocks referenced in customer snapshots. As a result of the software error, the EBS snapshot management system in the EU-West Region incorrectly thought some of the blocks were no longer being used and deleted them. We've addressed the error in the EBS snapshot system to prevent it from recurring.

We have now disabled all of your snapshots that contain these missing blocks. You can determine which of your snapshots were affected via the AWS Management Console or the DescribeSnapshots API call. The status for any affected snapshots will be shown as "error."

We have created copies of your affected snapshots where we've replaced the missing blocks with empty blocks. You can create a new volume from these snapshot copies and run a recovery tool on it (e.g. a file system recovery tool like fsck); in some cases this may restore normal volume operation. These snapshots can be identified via the snapshot Description field which you can see on the AWS Management Console or via the DescribeSnapshots API call. The Description field contains "Recovery Snapshot snap-xxxx" where snap-xxx is the id of the affected snapshot. Alternately, if you have any older or more recent snapshots that were unaffected, you will be able to create a volume from those snapshots without error. For additional questions, you may open a case in our Support Center:

We apologize for any potential impact this might have on your applications.

AWS Developer Support

This message was produced and distributed by Amazon Web Services LLC, 410 Terry Avenue North, Seattle, Washington 98109-5210