[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8732?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14712905#comment-14712905
 ] 

ASF subversion and git services commented on CLOUDSTACK-8732:
-------------------------------------------------------------

Commit e2a0d18a84c03593c64176b214cb805806f4d37d in cloudstack's branch 
refs/heads/master from [~rohit.ya...@shapeblue.com]
[ https://git-wip-us.apache.org/repos/asf?p=cloudstack.git;h=e2a0d18 ]

Merge pull request #696 from iwebhosting/rbd-live-resize

Default to notify only script to handle non-CLVM/QCOW cases.This relates to 
[CLOUDSTACK-8732](https://issues.apache.org/jira/browse/CLOUDSTACK-8732)

Before this commit the call to `getResizeScriptType` would throw an exception 
(earlier versions returned `null`, which was fine) - this caused the RBD case 
to fail. By changing the default to notify only we fix the case for any 
non-CLVM and non-QCOW cases, too.

This is RBD for now, but this should extend to new storage types supported by 
Libvirt natively in future.

This is my first attempted contribution: I can see a case for adding RBD logic 
to the actual getResizeScriptType call, too, but I felt that putting it 
`LibvirtResizeVolumeCommandWrapper.java` kept the special-casing of RBD (and 
comments about that) in one place.

### Caveat:

With Libvirt 1.2.2 this actually doesn't do the right thing - but it does do 
what the documentation *says* should be the right thing, so I'm going to test 
if this is a Libvirt bug which is fixed in a later version.

(To make it work I need to execute something like:

    virsh blockresize --path vda --size 100G i-7-44-VM

where vda is the path as far as the *guest* is concerned, and not an `rbd/` 
path - which *should* work, but doesn't.)

* pr/696:
  Default to notify only script to handle non-CLVM/QCOW cases.

Signed-off-by: Rohit Yadav <rohit.ya...@shapeblue.com>


> Unable to resize RBD volume: "Cannot determine resize type from pool type RBD"
> ------------------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-8732
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8732
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the 
> default.) 
>    Affects Versions: 4.5.1
>         Environment: Ubuntu 14.04, libvirt 1.2.2, qemu 2.0.0, ceph 0.94.2, 
> Cloudstack 4.5.1, Kernel 3.16.0, KVM hypervisor
>            Reporter: Darren Worrall
>
> First time reporter, so apologies early on if I've gotten anything wrong here.
> While trying to resize a RBD backed volume in our 4.5.1 installation (using 
> the {{resizeVolume}} api call), the job fails with the error above. A [pull 
> request|https://github.com/apache/cloudstack/pull/281] was merged in this 
> space but it seems incomplete - you can see that {{getResizeScriptType}} in 
> the source branch [returns 
> null|https://github.com/remibergsma/cloudstack/blob/a26bbc2ce2f99e706895f9c0bbc6bdb5a522c37f/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1824],
>  but currently in master the above exception [is 
> thrown|https://github.com/apache/cloudstack/blob/792c27c9bd97bc703ceb28fa8db24db7d0d46012/plugins/hypervisors/kvm/src/com/cloud/hypervisor/kvm/resource/LibvirtComputingResource.java#L1428]
> You can see a management server log snippet 
> [here|https://gist.githubusercontent.com/DazWorrall/3bfcb153dea8b137f38b/raw/1f41096b247221e26b5407ae777f5fe278614d54/management-server.log],
>  compete with traces.
> This was discussed on the [mailing 
> list|http://mail-archives.us.apache.org/mod_mbox/cloudstack-dev/201505.mbox/%3ccamvtbpou4tkan2kzknzpl0scu3y032ghu3av2qzgtsfas3t...@mail.gmail.com%3E]
>  but I cant see if anything came of it. I can confirm the findings there 
> though - going underneath Cloudstack and dealing with libvirt directly works 
> fine, I can live resize root and data volumes without issue.



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

Reply via email to