[openstack-dev] [nova] bp proposal: libvirt-resize-disk-down

Jay Pipes jaypipes at gmail.com
Thu Jan 30 15:42:27 UTC 2014


On Thu, 2014-01-30 at 14:59 +0000, sahid wrote:
> <snip>
> The implementation will be separated in several commits:
>   + Move shared utility methods to a common module:
>     - virt.xenapi.vm_utils._get_partitions to virt.disk.utils.get_partitions
>     - virt.libvirt.utils.copy_image to virt.disk.utils.copy_image
>     - virt.xenapi.vm_utils._repair_filesystem to virt.disk.utils.repair_filesystem
>   + Disk resize down implementation

Above looks like a good plan, and +1 for pulling useful generic code out
of a particular driver into a reusable library.

> Notes:
>   - Another point we have to discuss, is that the current implementation just skips
>     the fs resize if not supported, is it a good choice? 

For metering/usage purposes, does the old size of ephemeral disk
continue to be shown in usage records, or does the size of the disk in
the newly-selected instance type (flavor) get used? If the former, then
this would be an avenue for users to Get more disk space than they are
paying for. Something to look into...

Best,
-jay

> Should we have
>     to raise an exception to inform the user that it is not possible to resize
>     the instance? (if we have to raise an exception, a task will be added to the
>     TODO to handle this case for resize up before working on resize down.)
>   - The current workflow for a user is to confirm the resize when the state
>     of the instance is VERIFY_RESIZE, I think we probably have to add a
>     checklist of good pratices of how to verify a resize in the manual:
>       http://docs.openstack.org/user-guide/content/nova_cli_resize.html
> 
> Thanks a lot,
> s.
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev





More information about the OpenStack-dev mailing list