Mailing-List: contact issues-help@cloudstack.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cloudstack.apache.org
Date: Sat, 11 Mar 2017 12:39:04 +0000 (UTC)
From: "ASF GitHub Bot (JIRA)" <jira@apache.org>
To: cloudstack-issues@incubator.apache.org
Message-ID: <JIRA.13022780.1479889518000.9895.1489235944358@Atlassian.JIRA>
In-Reply-To: <JIRA.13022780.1479889518000@Atlassian.JIRA>
References: <JIRA.13022780.1479889518000@Atlassian.JIRA> <JIRA.13022780.1479889518862@jira-lw-us.apache.org>
Subject: [jira] [Commented] (CLOUDSTACK-9604) Root disk resize support for
 VMware and XenServer
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
archived-at: Sat, 11 Mar 2017 12:39:11 -0000


    [ 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)