[ https://issues.apache.org/jira/browse/CLOUDSTACK-9604?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15904989#comment-15904989 ]
ASF GitHub Bot commented on CLOUDSTACK-9604: -------------------------------------------- Github user borisstoyanov commented on the issue: https://github.com/apache/cloudstack/pull/1813 Hi @priyankparihar, I've set the vmware.root.disk.controller to iscsi, and got the following: ``` 2017-03-10 12:07:47,630 DEBUG [c.c.a.m.DirectAgentAttache] (DirectAgent-1:ctx-fa3e95c6) (logid:1d1dda75) Seq 1-2727211049349545996: Executing request 2017-03-10 12:07:47,631 INFO [c.c.h.v.r.VmwareResource] (DirectAgent-1:ctx-fa3e95c6 10.2.2.23, job-66/job-67, cmd: StartCommand) (logid:3be8ee6e) Executing resource StartCommand: {"vm":{"id":15,"name":"i-2-15-VM","bootloader":"HVM","type":"User","cpus":1,"minSpeed":250,"maxSpeed":500,"minRam":536870912,"maxRam":536870912,"hostName":"VM-ec57ee69-4604-4eb8-8460-2d9152216239","arch":"x86_64","os":"CentOS 5.3 (64-bit)","platformEmulator":"centos64Guest","bootArgs":"","enableHA":false,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"UcWxqITdc_kGyQEoT76Nog","params":{"deployvm":"true","dataDiskController":"osdefault","memoryOvercommitRatio":"1.0","nestedVirtualizationFlag":"false","cpuOvercommitRatio":"2.0","vmware.reserve.mem":"false","vmware.reserve.cpu":"false","nicAdapter":"E1000","rootDiskController":"iscsi"},"uuid":"ec57ee69-4604-4eb8-8460-2d9152216239","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"4943afe9-a45b-4d28-8c46-b11b9bb6369a","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"45c46701-09f6-3ae1-b322-192709c67bf8","id":1,"poolType":"NetworkFilesystem","host":"10.2.0.16","path":"/acs/primary/pr1813-t948-vmware-55u3/pr1813-t948-vmware-55u3-esxi-pri1","port":2049,"url":"NetworkFilesystem://10.2.0.16/acs/primary/pr1813-t948-vmware-55u3/pr1813-t948-vmware-55u3-esxi-pri1/?ROLE=Primary&STOREUUID=45c46701-09f6-3ae1-b322-192709c67bf8","isManaged":false}},"name":"ROOT-15","size":2147483648,"path":"ROOT-15-000001","volumeId":11,"vmName":"i-2-15-VM","accountId":2,"format":"OVA","provisioningType":"THIN","id":11,"deviceId":0,"bytesReadRate":0,"bytesWriteRate":0,"iopsReadRate":0,"iopsWriteRate":0,"hypervisorType":"VMware"}},"diskSeq":0,"path":"ROOT-15-000001","type":"ROOT","_details":{"storageHost":"10.2.0.16","managed":"false","storagePort":"2049","volumeSize":"2147483648"}},{"data":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"id":0,"format":"ISO","accountId":0,"hvm":false}},"diskSeq":3,"type":"ISO"}],"nics":[{"deviceId":0,"networkRateMbps":200,"defaultNic":true,"pxeDisable":false,"nicUuid":"8a911398-8512-4d3d-8c79-2fee06faf5a5","uuid":"9b2c0464-d6b4-4fe2-a9c4-433dcc3ada3c","ip":"10.1.1.22","netmask":"255.255.255.0","gateway":"10.1.1.1","mac":"02:00:39:d2:00:03","dns1":"8.8.8.8","dns2":"8.8.4.4","broadcastType":"Vlan","type":"Guest","broadcastUri":"vlan://976","isolationUri":"vlan://976","isSecurityGroupEnabled":false,"name":"vSwitch1,,vmwaresvs"}]},"hostIp":"10.2.2.23","executeInSequence":true,"wait":0} 2017-03-10 12:07:47,632 WARN [c.c.a.m.DirectAgentAttache] (DirectAgent-1:ctx-fa3e95c6) (logid:3be8ee6e) Seq 1-2727211049349545996: Throwable caught while executing command com.cloud.utils.exception.CloudRuntimeException: Invalid root disk controller detected : none at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:1539) at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:467) at com.cloud.agent.manager.DirectAgentAttache$Task.runInContext(DirectAgentAttache.java:315) at org.apache.cloudstack.managed.context.ManagedContextRunnable$1.run(ManagedContextRunnable.java:49) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:56) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:103) at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:53) at org.apache.cloudstack.managed.context.ManagedContextRunnable.run(ManagedContextRunnable.java:46) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) at java.util.concurrent.FutureTask.run(FutureTask.java:266) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at java.lang.Thread.run(Thread.java:745) ``` This looks like code issue since we can see it passed the StartCommand with `"rootDiskController":"iscsi"` but then exception appears: `Invalid root disk controller detected : none` > 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)