[
https://issues.apache.org/jira/browse/CLOUDSTACK-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15906190#comment-15906190
]
ASF GitHub Bot commented on CLOUDSTACK-9604:
--------------------------------------------
Github user priyankparihar commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1813#discussion_r105532534
--- Diff: test/integration/component/test_rootvolume_resize.py ---
@@ -0,0 +1,1140 @@
+# Licensed to the Apache Software Foundation (ASF) under one
+# or more contributor license agreements. See the NOTICE file
+# distributed with this work for additional information
+# regarding copyright ownership. The ASF licenses this file
+# to you under the Apache License, Version 2.0 (the
+# "License"); you may not use this file except in compliance
+# with the License. You may obtain a copy of the License at
+#
+# http://www.apache.org/licenses/LICENSE-2.0
+#
+# Unless required by applicable law or agreed to in writing,
+# software distributed under the License is distributed on an
+# "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+# KIND, either express or implied. See the License for the
+# specific language governing permissions and limitations
+# under the License.
+
+""" P1 tests for testing resize of root volume functionality
+
+ Test Plan: https://cwiki.apache.org/confluence/display/CLOUDSTACK/
+ Root+Resize+Support
+
+ Issue Link: https://issues.apache.org/jira/browse/CLOUDSTACK-9829
+"""
+# Import Local Modules
+from nose.plugins.attrib import attr
+from marvin.cloudstackTestCase import cloudstackTestCase, unittest
+from marvin.lib.base import (Account,
+ ServiceOffering,
+ VirtualMachine,
+ Resources,
+ Domain,
+ Volume,
+ Snapshot,
+ Template,
+ VmSnapshot,
+ Host,
+ Configurations,
+ StoragePool)
+from marvin.lib.common import (get_domain,
+ get_zone,
+ get_template,
+ matchResourceCount,
+ list_snapshots,
+ list_hosts,
+ list_configurations,
+ list_storage_pools)
+from marvin.lib.utils import (cleanup_resources,
+ validateList)
+from marvin.codes import (PASS,
+ FAIL,
+ FAILED,
+ RESOURCE_PRIMARY_STORAGE,
+ INVALID_INPUT)
+from marvin.lib.utils import checkVolumeSize
+import time
+from marvin.sshClient import SshClient
+
+
+class TestResizeVolume(cloudstackTestCase):
+ @classmethod
+ def setUpClass(cls):
+ cls.testClient = super(TestResizeVolume, cls).getClsTestClient()
+ cls.api_client = cls.testClient.getApiClient()
+ cls.hypervisor = (cls.testClient.getHypervisorInfo()).lower()
+ cls.storageID = None
+ # Fill services from the external config file
+ cls.services = cls.testClient.getParsedTestDataConfig()
+ # Get Zone, Domain and templates
+ cls.domain = get_domain(cls.api_client)
+ cls.zone = get_zone(
+ cls.api_client,
+ cls.testClient.getZoneForTests())
+ cls.services["mode"] = cls.zone.networktype
+ cls._cleanup = []
+ cls.unsupportedStorageType = False
+ cls.unsupportedHypervisorType = False
+ cls.updateclone = False
+ if cls.hypervisor not in ['xenserver',"kvm","vmware"]:
+ cls.unsupportedHypervisorType=True
+ return
+ cls.template = get_template(
+ cls.api_client,
+ cls.zone.id
+ )
+ cls.services["virtual_machine"]["zoneid"] = cls.zone.id
+ cls.services["virtual_machine"]["template"] = cls.template.id
+ cls.services["volume"]["zoneid"] = cls.zone.id
+ try:
+ cls.parent_domain = Domain.create(cls.api_client,
+ services=cls.services[
+ "domain"],
+ parentdomainid=cls.domain.id)
+ cls.parentd_admin = Account.create(cls.api_client,
+ cls.services["account"],
+ admin=True,
+
domainid=cls.parent_domain.id)
+ cls._cleanup.append(cls.parentd_admin)
+ cls._cleanup.append(cls.parent_domain)
+ list_pool_resp = list_storage_pools(cls.api_client,
+
account=cls.parentd_admin.name,domainid=cls.parent_domain.id)
+ res = validateList(list_pool_resp)
+ if res[2]== INVALID_INPUT:
+ raise Exception("Failed to list storage pool-no
storagepools found ")
+ #Identify the storage pool type and set vmware fullclone to
true if storage is VMFS
+ if cls.hypervisor == 'vmware':
+ for strpool in list_pool_resp:
+ if strpool.type == "VMFS":
--- End diff --
ping @sadhugit
> 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
> Attachments: 1.png, 2.png, 3.png
>
>
> 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.
> Web Services APIs
> resizeVolume API call will not change, but it will accept volume UUIDs of
> root volumes in id parameter for resizing.
> deployVirtualMachine API call will allow new rootdisksize parameter to be
> passed. This parameter will be used as the disk size (in GB) when cloning
> from template.
> UI
> 1) (refer attached image 1) shows UI that resize volume option is added for
> ROOT disks.
> 2) (refer attached image 2) when user calls the resize volume on ROOT volume.
> Here only size option is shown. For DATADISK disk offerings are shown.
> 3) (refer attached image 3) when user deploys VM. New option for Root disk
> size is added.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)