incubator-cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Marcus Sorensen" <>
Subject Re: Review Request: resize volume initial implementation
Date Tue, 25 Sep 2012 17:27:37 GMT

This is an automatically generated e-mail. To reply, visit:

(Updated Sept. 25, 2012, 5:27 p.m.)

Review request for cloudstack.


added diskofferingid. Now users can only resize DATA volumes, and there are limitations on
when/how they can resize to accomodate business logic. Users can enumerate the disk offerings
that the admins have provided, and choose a new one. If the tags match between disk offerings
then the volume will resize to the new disk offering size. If the current offering is custom
sized offering, users can resize simply by providing a new size. If the new offering being
migrated to is custom size, size parameter must also be provided.


Initial implementation of resize volumes. Works only for KVM but can be easily used to add
in other hypervisors. Works with local,sharedmountpoint,NFS,and CLVM storage. This is a significant
chunk of code and my first attempt at a new API call so please let me know if there are any
issues with where/how things are done.

This KVM implementation includes a host script "" because of several current
limitations. 1) we don't seem to have java bindings for virStorageVolResize() or virDomainBlockResize(),
and even if we did, virStorageVolResize() doesn't work for logical volume pools. It will presumably
be awhile before that's patched and available on current distros.

New API call is 'resizeVolume', with parameters: 

'id' for volume id

'size' for new size, accepts things like 10G, 10240M, 10485760K, 10737418240B or 10737418240

'shrinkok' this one is a boolean that confirms the user is ok with the volume shrinking. I
did this because it seems reasonable that someone might want to give back storage, and since
it's potentially dangerous (users need to free up the end of the block device that they want
to give back) there needs to be some sort of signoff. This can be disabled/removed if others
think it's too much of a liability. The code checks size twice, comparing the requested size
once against what we think the volume size is per database, and once again comparing the actual
qcow2/lv size against the requested size, both times ensuring that shrinkok is true before

If the resize succeeds, but libvirt fails to live update qemu of the new size (whether due
to bug, non-virtio disks, or something else), there's currently no indication other than that
the API call returns the new size as seen from libvirt, which itself should be an indication
that a powercycle is needed if the API call succeeds, the size is what was requested, and
the host isn't seeing the new size. Perhaps a field should be added, like 'rebootrequired:true'
to make it easy.

One thing I haven't tackled at all is how to handle the service offering fields.  If someone
has a service offering with a static 5GB discription like the default storage offerings have,
that won't change. Suggestions welcome. Should we update the service offering to custom, or
could that mess up other things like tags?

Diffs (updated)

  api/src/com/cloud/api/ 067ddf7 
  api/src/com/cloud/event/ e84a403 
  api/src/com/cloud/storage/ 4fb3b55 
  api/src/com/cloud/storage/ 6e8e48e 
  client/tomcatconf/ e233694 
  server/src/com/cloud/storage/ fc6fb5b 



Tested CLVM,NFS,local,sharedmountpoint, qcow2 and lvm formats

create test volumes on above listed pools, attach to VM instance

within instance, format as ext4, populate with files, grow, resize filesystem: pass

within instance, format as ext4, populate with files, shrink filesystem, shrink volume, unmount,
fsck, remount: pass

try passing bad arguments to API call fails as expected

try resizing as wrong user fails as expected

force to fail through various means bubbles the error up as expected, resets
the volume state to Ready


Marcus Sorensen

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message