Bug Reference

https://issues.apache.org/jira/browse/CLOUDSTACK-6181

Branch

branch resize-root

Feature Specifications

   Per the JIRA bug, administrators don't want to deploy duplicate OS templates of differing sizes just to support different storage packages. Instead, the VM deployment can accept a size for the root disk and adjust the template clone accordingly. In addition, CloudStack already supports data disk resizing for existing volumes, we can extend that functionality to resize existing root disks. KVM support will be added initially, and other hypervisor developers are welcome to add it to their code if/when they see fit.

Architecture and Design description

   As mentioned, we can leverage the existing design for resizing an existing volume. The difference with root volumes is that we can't resize via disk offering, therefore we need to verify that no disk offering was passed, just a size. The existing enforcements of new size < existing size will still server their purpose.

   For deployment-based resize, we pass the rootdisksize parameter when the existing code allocates the root volume. In the process, we validate that the root disk size is > existing template size, and non-zero. This will persist the root volume as the desired size regardless of whether or not the VM is started on deploy. Then hypervisor specific code needs to be made to pay attention to the VolumeObjectTO's size attribute and use that when doing the work of cloning from template, rather than inheriting the template's size. This can be implemented one hypervisor at a time, and as such there needs to be a check in UserVmManagerImpl to fail unsupported hypervisors with InvalidParameterValueException when the rootdisksize is passed.

   Integration tests added need to encompass resize-on-deploy, resize-on-existing, validate that passing a size too small fails with graceful error message, and validate that unsupported hypervisors fail with graceful error message. There are no changes required to any Commands or interfaces, per the state of master when branch was created, so we assume existing unit tests will suffice.

Web Services APIs

resizeVolume API call will not change, but it will accept volume UUIDs of root volumes for resizing.

deployVirtualMachine API call will allow new rootdisksize parameter to be passed. This parameter will be used as the disk size when cloning from template.

UI

UI support normally lags behind API support. There was already a 'root size' dialog accidentally added in 4.3 and then removed, which was just on the new instance wizard during template selection. We assume this will be reinstated some time after the API work is complete.