libvirt driver doesn't support disk re-size down

[Sahid Orentino]

Currently libvirt driver doesn't support resizing disk down.

During a resizing down all run well and the instance is updated to the new flavor with the new disk size.
but in real the disk is not resized and keep the original size.

We need to add the support of resizing down:
1. resizing the fs
2. resizing the image

For the step one we have to be sure we work with only one partition and we don't erase data.

what to do for the support of ntfs?

[Pádraig Brady (p-draigbrady)]

Resizing down is much more trick to do and I'm not sure how general it is.
Also there is logic in place to reject images that are too large in the first place (for DoS reasons).
So do we really need to support this?

[Rafi Khardalian (rkhardalian)]

There is really no safe way to do this. When resizing up, we can take a "best effort" approach in regards to anything having to do with the filesystem, which isn't the case with down. Without shrinking the filesystem before said downward resize, we'll be destroying data. Only AMIs are even structured to allow us to reliably do anything with the filesystem.

There are way too many ifs; this isn't something we should do.

[Sahid Orentino (sahid-ferdjaoui)]

About the risk of the implementation, in the workflow of a resize, every modifications on the disk are doing in a copy. The user is asked to check if all run well: during this step the user can check the console-log and connect itself on the instance to check if all is OK.
    if all is ok he just have to confirm the resize (resize-confirm).
    if something wrong he can do a revert (resize-revert)

The implementation of xenapi seems to support this feature. For vmware, it is not implemented yet (only extend).

Other things:
   From the user point of view when he checks the details of his instance after doing a resize down It will see the new space of disk (ex: from 50Go to 20Go) but in real nothing has change, the disk is always 50Go. It could be a source of misunderstood.

  From the provider point of view, he will now billed the user for a space allocated of 20Go but 50Go are allocated.

  What happens about the scheduler when it will check the free space of an host?

[Chet Burgess (cfb-n)]

Orthogonally but related, as pointed out the resize today will succeed and all references in the DB will be updated to the smaller size but the disk will remain the larger size.

This makes it impossible to accurately report on cloud allocation as the DB and API will now return an inaccurate result. We should consider actually making the resize fail during the prep phase if its a downgrade in size to prevent this type of reporting issue.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/74739

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/74739
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=6943f433bfb777a2eafccde2ef5c985c091b5bb9
Submitter: Jenkins
Branch: master

commit 6943f433bfb777a2eafccde2ef5c985c091b5bb9
Author: Sahid Orentino Ferdjaoui <email address hidden>
Date: Wed Feb 19 19:41:32 2014 +0100

    libvirt: raises exception when attempt to resize disk down

    Raises an exception when trying to resize an instance that needs to
    resize the disk down.

    Change-Id: Ic0a0bede744a1aacd057c5db9de3307b61c525b4
    Related-Bug: #1270238

[Markus Zoeller (markus_z) (mzoeller)]

This wishlist bug has been open a year without any activity. I'm going to move it to "Opinion / Wishlist", which is an easily-obtainable queue of older requests that have come on.

In case you want to work on that, consider writing a blueprints [1] and spec [2]. I'll recommend to read [3] if not yet done. The effort to implement the requested feature is then driven only by the blueprint (and spec).

References:
[1] https://blueprints.launchpad.net/nova/
[2] https://github.com/openstack/nova-specs
[3] https://wiki.openstack.org/wiki/Blueprints