Open Stack

Vish,

We've talked about this idea in the past and I agree this works for *nix
hosts, but a base install of Windows 2k8R2 with CloudServers is 10.7GB. If
we went with a 10gb base disk solution this obviously won't work. Even if we
went with a 20gb partition it could become a problem as users install
programs to C: and then try to do system updates that expect to have some
reasonable disk available on C:. Providing a clean install with < 10gb
usable doesn't feel like a good customer experience. We could go with a 30gb
or 40gb fixed disk but that doesn't sound very flexible for all users.

I wanted to include some context to why we do it this way and how I
envisioned this working.

We have some users that wish to format their disk with other filesystems for
performance reasons or encrypt them for security reasons. Both of these are
completely valid. However, this poses a problem if we were to try to resize
these partitions for them. Easy solution is don't touch the partitions and
let them do it themselves. I think this type of solution works well for
power users and developers. This does pose a problem for less technical
users who would resize a disk and then wonder why they don't see the extra
space as expected. This would create extra support costs that not all
providers are willing to shoulder.

To address this, we designed what we felt was a compromise and let the users
decide what they feel is the best solution. It would be an extension that
would let users define what kind of disk management they wish to use,
'manual' or 'auto'. Manual would be the hands off approach that would tell
the system to expand the disk, but not touch the partition.

Auto would expand the disk along with the partition. The caveat with the
auto expand would be the filesystem would have to be in a format that the
host understood. If it is a FS that the compute node isn't prepared to deal
with, it errors.If this instance is set to auto and the customer requests a
resize, the compute node would mount the FS, check for the right partition
boundaries and type and expand the disk. If the partition boundaries aren't
what the system expects, it errors. This scheme would allow users that wish
to scale vertically with their instance inflate their instance then deflate
it. It would entail copying the data to a smaller disk, but the customers
that use this feature see this as unique and useful.

The proposal as I understand it would help in all manual situations but not
with customers that wish to use obtuse filesystem options.

If anyone can think of other ways to handle this, I would love to discuss.

pvo


On Wed, Aug 31, 2011 at 4:24 PM, Chris Behrens
<chris.behrens at rackspace.com>wrote:

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