Open Stack

Vish,

I think Rackspace ozone/titan has some upcoming work to do for the resizing for xenserver that might close some of the gap.

I think we need some options (flags) if we are to synchronize libvirt/xen.  At some point, Rackspace also needs an API extension to support a couple different ways of handling resizes.  Until we get there, we at least need an option to keep the xenserver code working as-is for now.  I assume others need the current libvirt implementation to stay as well.

That said, I think it's probably not too difficult to do the 'libvirt way' for Xen, but I don't know about it making diablo.
Adding support into libvirt to do the 'xen way' should be easier, I'd think.  But I'm the opposite of you, Vish.  I don't know the libvirt layer as well. :)

If we can FLAG the way it works... and make these options work in both libvirt/xen, I think we can all remain happy.

- Chris

On Aug 31, 2011, at 11:45 AM, Vishvananda Ishaya wrote:

> 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.
> 
> 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 first method:
> 
> 1) The actual space used by the image is local_gb + 10G (or more if the base image is larger than 10G) which is inconsistent.
> 
> 2) The guest has to deal with the annoyance of not having one large filesystem.  It is easier for the user if they can just use all the space that they have without thinking about it.
> 
> 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.
> 
> 
> We need to decide on a common strategy and use it for both hypervisors.
> 
> Vish
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack at lists.launchpad.net
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp

This email may include confidential information. If you received it in error, please delete it.