[Openstack] libvirt vs. Xen driver handling of local storage

Vishvananda Ishaya vishvananda at gmail.com
Wed Aug 31 18:45:39 UTC 2011


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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack/attachments/20110831/d486d235/attachment.html>


More information about the Openstack mailing list