Open Stack

2011/8/31 Vishvananda Ishaya <vishvananda at gmail.com>:
> Hey guys,
> We have a very annoying discrepancy between how local space is used in the
> xen driver vs the libvirt driver.  I think it is vital that this is
> rectified before the Diablo release.  We already have a few functional gaps
> between the drivers, but the fact that disks are partitioned completely
> differently between the two is very confusing to users.

Great! As you point out, there are a lot of these, and I'm very happy
that we're starting to sort those out, so thanks for raising this.

> Bug is here: https://bugs.launchpad.net/nova/+bug/834189
> The libvirt driver:
> * downloads the image from glance
> * resizes the image to 10G if it is < 10G
> (in the case of a separate kernel and ramdisk image it extends the
> filesystem as well.  In the case of a whole-disk image it just resizes the
> file because it doesn't know enough to change the filesystem)
> * attaches a second disk the size of local_gb to the image
> (when using block device mapping through the ec2 api, more swap/ephemeral
> disks can be attached as volumes as well)
> The XenServer driver (I'm less familiar with this code so please correct me
> if i am wrong here):
> * downloads the image from glance
> * creates a vdi from the base image
> * resizes the vdi to the size of local_gb
> The first method of resize to 10G and having separate local_gb is
> essentially the strategy taken by aws.
[...]
> Drawbacks of the second method:
> 1) Limits cloud images to a particular format.  We can't always guarantee
> that we can resize the image properly.

Can you elaborate on this? Both methods resize the disk, how does the
second method impose more limitations than the first?


-- 
Soren Hansen        | http://linux2go.dk/
Ubuntu Developer    | http://www.ubuntu.com/
OpenStack Developer | http://www.openstack.org/