cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Priyank Parihar (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CLOUDSTACK-9604) Root disk resize support for VMware and XenServer
Date Wed, 23 Nov 2016 10:01:11 GMT

     [ https://issues.apache.org/jira/browse/CLOUDSTACK-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Priyank Parihar updated CLOUDSTACK-9604:
----------------------------------------
    Description: 
Currently the root size of an instance is locked to that of the template. This creates unnecessary
template duplicates, prevents the creation of a market place, wastes time and disk space and
generally makes work more complicated.
Real life example - a small VPS provider might want to offer the following sizes (in GB):
10,20,40,80,160,240,320,480,620
That's 9 offerings.
The template selection could look like this, including real disk space used:
Windows 2008 ~10GB
Windows 2008+Plesk ~15GB
Windows 2008+MSSQL ~15GB
Windows 2012 ~10GB
Windows 2012+Plesk ~15GB
Windows 2012+MSSQL ~15GB
CentOS ~1GB
CentOS+CPanel ~3GB
CentOS+Virtualmin ~3GB
CentOS+Zimbra ~3GB
CentOS+Docker ~2GB
Debian ~1GB
Ubuntu LTS ~1GB
In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If
your storage is expensive and limited SSD this can get painful!
If the root resize feature is enabled we can reduce this to under 100 GB.

Specifications and Description 
    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. 
  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 (ROOT volume size different from template size), 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.
   


Hypervisor specific changes
XenServer
Resize ROOT volume is only supported for stopped VMs
Newly created ROOT volume will be resized after clone from template

VMware  
Resize ROOT volume is only supported for stopped VMs.
New size should be large then the previous size.
Newly created ROOT volume will be resized after clone from template iff
 There is no root disk chaining.(means use Full clone)
And Root Disk controller setting is not  IDE.
Previously created Root Volume could be resized iif
There is no root disk chaining.
And Root Disk controller setting is not  IDE.



  was:
Currently the root size of an instance is locked to that of the template. This creates unnecessary
template duplicates, prevents the creation of a market place, wastes time and disk space and
generally makes work more complicated.
Real life example - a small VPS provider might want to offer the following sizes (in GB):
10,20,40,80,160,240,320,480,620
That's 9 offerings.
The template selection could look like this, including real disk space used:
Windows 2008 ~10GB
Windows 2008+Plesk ~15GB
Windows 2008+MSSQL ~15GB
Windows 2012 ~10GB
Windows 2012+Plesk ~15GB
Windows 2012+MSSQL ~15GB
CentOS ~1GB
CentOS+CPanel ~3GB
CentOS+Virtualmin ~3GB
CentOS+Zimbra ~3GB
CentOS+Docker ~2GB
Debian ~1GB
Ubuntu LTS ~1GB
In this case the total disk space used by templates will be 828 GB, that's almost 1 TB. If
your storage is expensive and limited SSD this can get painful!
If the root resize feature is enabled we can reduce this to under 100 GB.



> Root disk resize support for VMware and XenServer
> -------------------------------------------------
>
>                 Key: CLOUDSTACK-9604
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9604
>             Project: CloudStack
>          Issue Type: Improvement
>      Security Level: Public(Anyone can view this level - this is the default.) 
>            Reporter: Priyank Parihar
>            Assignee: Priyank Parihar
>
> Currently the root size of an instance is locked to that of the template. This creates
unnecessary template duplicates, prevents the creation of a market place, wastes time and
disk space and generally makes work more complicated.
> Real life example - a small VPS provider might want to offer the following sizes (in
GB):
> 10,20,40,80,160,240,320,480,620
> That's 9 offerings.
> The template selection could look like this, including real disk space used:
> Windows 2008 ~10GB
> Windows 2008+Plesk ~15GB
> Windows 2008+MSSQL ~15GB
> Windows 2012 ~10GB
> Windows 2012+Plesk ~15GB
> Windows 2012+MSSQL ~15GB
> CentOS ~1GB
> CentOS+CPanel ~3GB
> CentOS+Virtualmin ~3GB
> CentOS+Zimbra ~3GB
> CentOS+Docker ~2GB
> Debian ~1GB
> Ubuntu LTS ~1GB
> In this case the total disk space used by templates will be 828 GB, that's almost 1 TB.
If your storage is expensive and limited SSD this can get painful!
> If the root resize feature is enabled we can reduce this to under 100 GB.
> Specifications and Description 
>     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. 
>   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 (ROOT volume size different from template size), 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.
>    
> Hypervisor specific changes
> XenServer
> Resize ROOT volume is only supported for stopped VMs
> Newly created ROOT volume will be resized after clone from template
> VMware  
> Resize ROOT volume is only supported for stopped VMs.
> New size should be large then the previous size.
> Newly created ROOT volume will be resized after clone from template iff
>  There is no root disk chaining.(means use Full clone)
> And Root Disk controller setting is not  IDE.
> Previously created Root Volume could be resized iif
> There is no root disk chaining.
> And Root Disk controller setting is not  IDE.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message