You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Chris Chupela <cc...@dsscorp.com> on 2016/04/21 23:06:27 UTC

RE: problem with vm volume resize [SOLVED]

The issue turned out to be that the backup software was attempting to backup the volume at the same time I was trying to resize it.  After making sure the backup wasn't running, I was able to resize the drive without issue.


Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | Twitter | Facebook

-----Original Message-----
From: Chris Chupela 
Sent: Wednesday, April 20, 2016 7:04 AM
To: users@cloudstack.apache.org
Subject: RE: problem with vm volume resize

The root disk resize isn't supported with vmware, but the disk I'm attempting to resize isn't a root disk. Based on what I've seen in the logs, the GUI, and in the vcenter properties for this instance, it appears the disk I'm attempting this on is identified correctly.  Disk 0:0 is the root, 0:1 is the first data disk, etc. It is this first data disk I'm attempting to resize. I've listed the rest of the log messages below, which show it running the command, finding the disk 0:1. Then the Java runtime error occurs. I haven't tried running the resize via cloudmonkey/api yet. I don't think its been vmotioned, but I'll have to check.


2016-04-19 22:52:45,001 DEBUG [agent.transport.Request] (AgentManager-Handler-3:null) Seq 39-717719634: Executing:  { Cmd , MgmtId: 345052112145, via: 39, Ver: v1, Flags: 100011, [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"path":"d4ef260d8182427a8b36fada13875278","pool":{"id":200,"uuid":"d01b5905-0cac-31b9-b25f-7b7641965829","host":"VMFS datastore: /WYO-DC1/WYO-P1-C1-PS1-ESX","path":"/WYO-DC1/WYO-P1-C1-PS1-ESX","port":0,"type":"VMFS"},"vmInstance":"i-27-387-VM","newSize":107374182400,"currentSize":53687091200,"shrinkOk":false,"wait":0}}] }

2016-04-19 22:52:45,001 DEBUG [agent.manager.DirectAgentAttache] (DirectAgent-88:null) Seq 39-717719634: Executing request
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Look for disk device info from volume : d4ef260d8182427a8b36fada13875278
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Test against disk device, controller key: 1000, unit number: 0
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Test against disk backing : [WYO-P1-C1-PS1-ESX] i-27-387-VM/2d51d2b060f84d12802b01b9b22098d8-000001.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Test against disk backing : [WYO-P1-C1-PS1-ESX] i-27-387-VM/2d51d2b060f84d12802b01b9b22098d8.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Test against disk device, controller key: 1000, unit number: 1
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Test against disk backing : [WYO-P1-C1-PS1-ESX] i-27-387-VM/d4ef260d8182427a8b36fada13875278-000001.vmdk
2016-04-19 22:52:45,111 INFO  [vmware.mo.VirtualMachineMO] (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd: ResizeVolumeCommand) Disk backing : [WYO-P1-C1-PS1-ESX] i-27-387-VM/d4ef260d8182427a8b36fada13875278-000001.vmdk matches ==> scsi0:1



Chris Chupela
Systems Engineer
DSS
610.927.2031 Office
610.334.2392 Cell

Website | Data Center | Twitter | Facebook

-----Original Message-----
From: Dag Sonstebo [mailto:Dag.Sonstebo@shapeblue.com]
Sent: Wednesday, April 20, 2016 4:28 AM
To: users@cloudstack.apache.org
Subject: Re: problem with vm volume resize

Chris - out of interest - has this VM been through a storage vMotion? We have come across an issue recently where a similar thing happened, the wrong disk was resized and our investigation so far shows this to potentially be caused by disks having been renamed during svMotion.


Dag Sonstebo






On 20/04/2016, 07:04, "Pavan Bandarupally" <pa...@accelerite.com> wrote:

>I think Root disk resize is supported only on KVM as per the FS 
>https://cwiki.apache.org/confluence/display/CLOUDSTACK/Root+Resize+Supp
>ort
>
>
>-----Original Message-----
>From: ilya [mailto:ilya.mailing.lists@gmail.com]
>Sent: Wednesday, April 20, 2016 11:23 AM
>To: users@cloudstack.apache.org
>Subject: Re: problem with vm volume resize
>
>device 0 implies root disk..
>
>On 4/19/16 9:26 PM, Simon Weller wrote:
>> Chris,
>> 
>> Device 0, if I'm not mistaken, normally refers to the root volume. Have you tried this via the api directly, or via cloudmonkey to eliminate the ui?
>> 
>> - Si
>> 
>> Simon Weller/ENA
>> (615) 312-6068
>> 
>> -----Original Message-----
>> From: Chris Chupela [cchupela@dsscorp.com]
>> Received: Tuesday, 19 Apr 2016, 10:57PM
>> To: users@cloudstack.apache.org [users@cloudstack.apache.org]
>> Subject: problem with vm volume resize
>> 
>> I have a cloudstack 4.2 installation with vmware 5.0 as the underlying hypervisor. I've resized volumes in the past using the web UI, but have run into an issue where my resize attempt on an existing win2k8 data volume failed. It is a resize from 50Gb to 100Gb, and I have enough storage to do the resize.
>> 
>> When I attempt the resize, the UI returns 'unable to resize volume', and I find the following error in the management server log:
>> 
>> 2016-04-19 22:52:45,468 ERROR [vmware.resource.VmwareResource] 
>> (DirectAgent-88:wyo1-p1-c1-hv5.dsscorp.com, job-641, cmd:
>> ResizeVolumeCommand) Unable to resize volume
>> java.lang.RuntimeException: Invalid operation for device '0'.
>>         at com.cloud.hypervisor.vmware.util.VmwareClient.waitForTask(VmwareClient.java:413)
>>         at com.cloud.hypervisor.vmware.mo.VirtualMachineMO.configureVm(VirtualMachineMO.java:862)
>>         at com.cloud.hypervisor.vmware.resource.VmwareResource.execute(VmwareResource.java:691)
>>         at com.cloud.hypervisor.vmware.resource.VmwareResource.executeRequest(VmwareResource.java:572)
>>         at com.cloud.agent.manager.DirectAgentAttache$Task.run(DirectAgentAttache.java:186)
>>         at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
>>         at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
>>         at java.util.concurrent.FutureTask.run(Unknown Source)
>>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(Unknown Source)
>>         at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(Unknown Source)
>>         at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source)
>>         at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
>>         at java.lang.Thread.run(Unknown Source)
>> 
>> The vm in question has been in the cloud enviornment/production for 2+ years. It has a root volume, and 3 data volumes. I'm trying to resize the first data volume.
>> 
>> I've seen some mention of issues like this with resizing volumes that were created from snapshots, but that doesn't apply here.
>> 
>> Any thoughts on why my resize attempt is failing?
>> 
>> Chris Chupela
>> Systems Engineer
>> DSS
>> 610.927.2031 Office
>> 610.334.2392 Cell
>> 
>> Website<http://www.dsscorp.com/> | Data 
>> Center<http://www.dssdatacenter.com/> | 
>> Twitter<http://www.twitter.com/DSSDataCenter> | 
>> Facebook<https://www.facebook.com/distributedsystemsservicesinc#!/Dis
>> tributedSystemsServices>
>> 
>> 
>
>
>
>DISCLAIMER
>==========
>This e-mail may contain privileged and confidential information which is the property of Accelerite, a Persistent Systems business. It is intended only for the use of the individual or entity to which it is addressed. If you are not the intended recipient, you are not authorized to read, retain, copy, print, distribute or use this message. If you have received this communication in error, please notify the sender and delete all copies of this message. Accelerite, a Persistent Systems business does not accept any liability for virus infected mails.

Regards,

Dag Sonstebo

Dag.Sonstebo@shapeblue.com
www.shapeblue.com
53 Chandos Place, Covent Garden, London  WC2N 4HSUK @shapeblue