You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Cloud List <cl...@sg.or.id> on 2018/08/16 10:07:54 UTC
Unable to resize down data disk: libvirt exception - invalid
argument: can't shrink capacity below existing allocation
Hi,
We are using CloudStack 4.8.1.1 with QEMU/KVM hypervisor, libvirt and Ceph
RBD storage.
We just realised that we are not able to resize down any of our data-disks,
and we are sure that we were able to do that before. Not too sure since
when the problem started to happen.
When we tried to resize a data disk of a VM on CloudStack admin panel by
stopping the VM and then go to Instance > VM hostname > View Volumes >
DATA-XXXX > Resize volume > Select a disk offering with lower storage size
> Tick on "Shrink OK" > click OK, we get this error messages as a pop-up on
the CloudStack admin panel:
====
org.libvirt.LibvirtException: invalid argument: can't shrink capacity below
existing allocation
====
On management server logs:
====
2018-08-16 17:52:31,541 ERROR [c.c.a.ApiAsyncJobDispatcher]
(API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Unexpected
exception while executing
org.apache.cloudstack.api.command.admin.volume.ResizeVolumeCmdByAdmin
com.cloud.utils.exception.CloudRuntimeException:
org.libvirt.LibvirtException: invalid argument: can't shrink capacity below
existing allocation
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:1213)
at
com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(VolumeApiServiceImpl.java:2920)
at sun.reflect.GeneratedMethodAccessor1400.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107)
at
com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(VolumeApiServiceImpl.java:2944)
at sun.reflect.GeneratedMethodAccessor1396.invoke(Unknown Source)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606)
at
org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:317)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:183)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:150)
at
org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
at
org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:172)
at
org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:204)
at com.sun.proxy.$Proxy194.handleVmWorkJob(Unknown Source)
at
com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102)
at
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
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
org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
at
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
at java.util.concurrent.FutureTask.run(FutureTask.java:262)
at
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
at java.lang.Thread.run(Thread.java:745)
2018-08-16 17:52:31,543 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Complete
async job-69196, jobStatus: FAILED, resultCode: 530, result:
org.apache.cloudstack.api.response.Except
ionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"org.libvirt.LibvirtException:
invalid argument: can\u0027t shrink capacity below existing allocation"}
====
On the hypervisor host's CloudStack agent log:
====
2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Request:Seq 76-5194057745242603743: { Cmd ,
MgmtId: 14038008226984, via: 76, Ver: v1, Flags: 100011,
[{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"p
ath":"0de865cf-cbd1-4b7b-8052-929ea7ebfc80","pool":{"id":214,"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","host":"
xxxx-yyy.xxxxxxxxx.com
","path":"xxxxxxxxx-yy-88","userInfo":"admin:xxxxxxxxxxxxxx","port":
6789,"type":"RBD"},"vmInstance":"i-3149-5290-VM","newSize":21474836480,"currentSize":42949672960,"shrinkOk":true,"wait":0}}]
}
2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Processing command:
com.cloud.agent.api.storage.ResizeVolumeCommand
2018-08-16 17:52:29,790 INFO [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-2:null) Trying to fetch storage pool
d433809b-01ea-3947-ba0f-48077244e4d6 from libvirt
2018-08-16 17:52:29,790 DEBUG [kvm.resource.LibvirtConnection]
(agentRequest-Handler-2:null) Looking for libvirtd connection at:
qemu:///system
2018-08-16 17:52:29,794 DEBUG [kvm.storage.LibvirtStorageAdaptor]
(agentRequest-Handler-2:null) Succesfully refreshed pool
d433809b-01ea-3947-ba0f-48077244e4d6 Capacity: 68604993286144 Used:
17779163430778 Available: 32956092846080
2018-08-16 17:52:30,002 DEBUG
[resource.wrapper.LibvirtResizeVolumeCommandWrapper]
(agentRequest-Handler-2:null) Volume
xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 is on a RBD storage
pool. No need to query for additional inf
ormation.
2018-08-16 17:52:30,002 DEBUG
[resource.wrapper.LibvirtResizeVolumeCommandWrapper]
(agentRequest-Handler-2:null) Resizing volume:
xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80,42949672960,21474836480,NOTIFYONLY,i-3149-5290-VM,t
rue
2018-08-16 17:52:30,002 DEBUG
[resource.wrapper.LibvirtResizeVolumeCommandWrapper]
(agentRequest-Handler-2:null) Volume
xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 can be resized by
libvirt. Asking libvirt to resize the volum
e.
2018-08-16 17:52:30,002 DEBUG [kvm.resource.LibvirtConnection]
(agentRequest-Handler-2:null) Looking for libvirtd connection at:
qemu:///system
2018-08-16 17:52:30,003 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-2:null) Seq 76-5194057745242603743: { Ans: , MgmtId:
14038008226984, via: 76, Ver: v1, Flags: 10,
[{"com.cloud.agent.api.storage.ResizeVolumeAnswer":{"newSize":0,"r
esult":false,"details":"org.libvirt.LibvirtException: invalid argument:
can't shrink capacity below existing allocation","wait":0}}] }
====
On the libvirtd.log:
====
2018-08-16 09:52:30.003+0000: 3599: error : storageVolResize:2164 : invalid
argument: can't shrink capacity below existing allocation
====
We are using libvirtd (libvirt) 1.2.3. Not too sure if it's the issue with
the libvirt version we are using?
Not too sure what existing allocation it refers to, is there any settings
under CloudStack related to this?
Resizing up a disk works fine, only resizing down will have this problem.
Anyone encountered this problem before? Any advice is greatly appreciated.
Looking forward to your reply, thank you.
Cheers.
AW: Unable to resize down data disk: libvirt exception - invalid
argument: can't shrink capacity below existing allocation
Posted by "Stock, Alexander" <Al...@itelligence.de>.
Hi,
has anybody an update on that Issue?
Does a libvirt upgrade solve the problem?
BR
Alexander
-----Ursprüngliche Nachricht-----
Von: Cloud List <cl...@sg.or.id>
Gesendet: Donnerstag, 20. September 2018 07:00
An: users@cloudstack.apache.org
Betreff: Re: Unable to resize down data disk: libvirt exception - invalid argument: can't shrink capacity below existing allocation
Hi Simon,
Thanks for your reply.
We are using Ubuntu OS on the hypervisor level. We compiled libvirtd from source (downloaded from libvirt website) and do not use the one from Ubuntu apt package. Currently using below version:
# libvirtd --version
libvirtd (libvirt) 1.2.3
Any clue what could be the problem? Do you think upgrading the libvirt will help?
Looking foward to your reply, thank you.
Cheers.
On Wed, Sep 19, 2018 at 8:07 PM Simon Weller <sw...@ena.com.invalid>
wrote:
> This looks like a libvirt limitation/bug. What OS are you using?
>
>
> ________________________________
> From: Cloud List <cl...@sg.or.id>
> Sent: Tuesday, September 18, 2018 11:34 PM
> To: users@cloudstack.apache.org
> Subject: Re: Unable to resize down data disk: libvirt exception -
> invalid
> argument: can't shrink capacity below existing allocation
>
> Hi,
>
> Anyone can advise on below? Or is it confirmed that resizing down
> (shrinking) the data-disk is no longer supported on CloudStack with
> KVM, libvirt and Ceph RBD storage?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Thu, Aug 16, 2018 at 6:07 PM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi,
> >
> > We are using CloudStack 4.8.1.1 with QEMU/KVM hypervisor, libvirt
> > and
> Ceph
> > RBD storage.
> >
> > We just realised that we are not able to resize down any of our
> > data-disks, and we are sure that we were able to do that before. Not
> > too sure since when the problem started to happen.
> >
> > When we tried to resize a data disk of a VM on CloudStack admin
> > panel by stopping the VM and then go to Instance > VM hostname >
> > View Volumes > DATA-XXXX > Resize volume > Select a disk offering
> > with lower storage
> size
> > > Tick on "Shrink OK" > click OK, we get this error messages as a
> > > pop-up
> on
> > the CloudStack admin panel:
> >
> > ====
> > org.libvirt.LibvirtException: invalid argument: can't shrink
> > capacity below existing allocation ====
> >
> > On management server logs:
> >
> > ====
> > 2018-08-16 17:52:31,541 ERROR [c.c.a.ApiAsyncJobDispatcher]
> > (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c)
> > Unexpected exception while executing org.apache.cloudstack.api.command.admin.volume.
> > ResizeVolumeCmdByAdmin
> > com.cloud.utils.exception.CloudRuntimeException:
> > org.libvirt.LibvirtException: invalid argument: can't shrink
> > capacity
> below
> > existing allocation
> > at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> > VolumeApiServiceImpl.java:1213)
> > at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> > VolumeApiServiceImpl.java:2920)
> > at sun.reflect.GeneratedMethodAccessor1400.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(
> > VmWorkJobHandlerProxy.java:107)
> > at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(
> > VolumeApiServiceImpl.java:2944)
> > at sun.reflect.GeneratedMethodAccessor1396.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at org.springframework.aop.support.AopUtils.
> > invokeJoinpointUsingReflection(AopUtils.java:317)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > proceed(ReflectiveMethodInvocation.java:150)
> > at org.springframework.aop.interceptor.
> > ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > proceed(ReflectiveMethodInvocation.java:172)
> > at org.springframework.aop.framework.JdkDynamicAopProxy.
> > invoke(JdkDynamicAopProxy.java:204)
> > at com.sun.proxy.$Proxy194.handleVmWorkJob(Unknown Source)
> > at com.cloud.vm.VmWorkJobDispatcher.runJob(
> > VmWorkJobDispatcher.java:102)
> > at org.apache.cloudstack.framework.jobs.impl.
> > AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> > 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 org.apache.cloudstack.framework.jobs.impl.
> > AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> > at java.util.concurrent.Executors$RunnableAdapter.
> > call(Executors.java:471)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1145)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > 2018-08-16 17:52:31,543 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> > (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c)
> > Complete async job-69196, jobStatus: FAILED, resultCode: 530, result:
> > org.apache.cloudstack.api.response.Except
> >
> ionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"org.libvirt.LibvirtException:
> > invalid argument: can\u0027t shrink capacity below existing
> > allocation"} ====
> >
> > On the hypervisor host's CloudStack agent log:
> >
> > ====
> > 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Request:Seq 76-5194057745242603743: {
> > Cmd
> ,
> > MgmtId: 14038008226984, via: 76, Ver: v1, Flags: 100011,
> > [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"p
> > ath":"0de865cf-cbd1-4b7b-8052-929ea7ebfc80","pool":{"id":
> > 214,"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","host":"
> > xxxx-yyy.xxxxxxxxx.com","path":"xxxxxxxxx-yy-88","userInfo":"admin:
> > xxxxxxxxxxxxxx","port":
> > 6789,"type":"RBD"},"vmInstance":"i-3149-5290-VM","newSize":21474836480,"
> > currentSize":42949672960,"shrinkOk":true,"wait":0}}] }
> > 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Processing command:
> > com.cloud.agent.api.storage.ResizeVolumeCommand
> > 2018-08-16 17:52:29,790 INFO [kvm.storage.LibvirtStorageAdaptor]
> > (agentRequest-Handler-2:null) Trying to fetch storage pool
> > d433809b-01ea-3947-ba0f-48077244e4d6 from libvirt
> > 2018-08-16 17:52:29,790 DEBUG [kvm.resource.LibvirtConnection]
> > (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> > qemu:///system
> > 2018-08-16 17:52:29,794 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> > (agentRequest-Handler-2:null) Succesfully refreshed pool
> > d433809b-01ea-3947-ba0f-48077244e4d6 Capacity: 68604993286144 Used:
> > 17779163430778 Available: 32956092846080
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null)
> > Volume
> > xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 is on a RBD
> > storage pool. No need to query for additional inf ormation.
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null)
> > Resizing
> > volume: xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80,
> > 42949672960,21474836480,NOTIFYONLY,i-3149-5290-VM,t
> > rue
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null)
> > Volume
> > xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 can be resized
> > by libvirt. Asking libvirt to resize the volum e.
> > 2018-08-16 17:52:30,002 DEBUG [kvm.resource.LibvirtConnection]
> > (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> > qemu:///system
> > 2018-08-16 17:52:30,003 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Seq 76-5194057745242603743: { Ans: ,
> MgmtId:
> > 14038008226984, via: 76, Ver: v1, Flags: 10, [{"com.cloud.agent.api.
> > storage.ResizeVolumeAnswer":{"newSize":0,"r
> > esult":false,"details":"org.libvirt.LibvirtException: invalid argument:
> > can't shrink capacity below existing allocation","wait":0}}] } ====
> >
> > On the libvirtd.log:
> >
> > ====
> > 2018-08-16 09:52:30.003+0000: 3599: error : storageVolResize:2164 :
> > invalid argument: can't shrink capacity below existing allocation
> > ====
> >
> > We are using libvirtd (libvirt) 1.2.3. Not too sure if it's the
> > issue
> with
> > the libvirt version we are using?
> >
> > Not too sure what existing allocation it refers to, is there any
> > settings under CloudStack related to this?
> >
> > Resizing up a disk works fine, only resizing down will have this problem.
> >
> > Anyone encountered this problem before? Any advice is greatly
> appreciated.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
>
Re: Unable to resize down data disk: libvirt exception - invalid
argument: can't shrink capacity below existing allocation
Posted by Cloud List <cl...@sg.or.id>.
Hi Simon,
Thanks for your reply.
We are using Ubuntu OS on the hypervisor level. We compiled libvirtd from
source (downloaded from libvirt website) and do not use the one from Ubuntu
apt package. Currently using below version:
# libvirtd --version
libvirtd (libvirt) 1.2.3
Any clue what could be the problem? Do you think upgrading the libvirt will
help?
Looking foward to your reply, thank you.
Cheers.
On Wed, Sep 19, 2018 at 8:07 PM Simon Weller <sw...@ena.com.invalid>
wrote:
> This looks like a libvirt limitation/bug. What OS are you using?
>
>
> ________________________________
> From: Cloud List <cl...@sg.or.id>
> Sent: Tuesday, September 18, 2018 11:34 PM
> To: users@cloudstack.apache.org
> Subject: Re: Unable to resize down data disk: libvirt exception - invalid
> argument: can't shrink capacity below existing allocation
>
> Hi,
>
> Anyone can advise on below? Or is it confirmed that resizing down
> (shrinking) the data-disk is no longer supported on CloudStack with KVM,
> libvirt and Ceph RBD storage?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
>
>
> On Thu, Aug 16, 2018 at 6:07 PM, Cloud List <cl...@sg.or.id> wrote:
>
> > Hi,
> >
> > We are using CloudStack 4.8.1.1 with QEMU/KVM hypervisor, libvirt and
> Ceph
> > RBD storage.
> >
> > We just realised that we are not able to resize down any of our
> > data-disks, and we are sure that we were able to do that before. Not too
> > sure since when the problem started to happen.
> >
> > When we tried to resize a data disk of a VM on CloudStack admin panel by
> > stopping the VM and then go to Instance > VM hostname > View Volumes >
> > DATA-XXXX > Resize volume > Select a disk offering with lower storage
> size
> > > Tick on "Shrink OK" > click OK, we get this error messages as a pop-up
> on
> > the CloudStack admin panel:
> >
> > ====
> > org.libvirt.LibvirtException: invalid argument: can't shrink capacity
> > below existing allocation
> > ====
> >
> > On management server logs:
> >
> > ====
> > 2018-08-16 17:52:31,541 ERROR [c.c.a.ApiAsyncJobDispatcher]
> > (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Unexpected
> > exception while executing org.apache.cloudstack.api.command.admin.volume.
> > ResizeVolumeCmdByAdmin
> > com.cloud.utils.exception.CloudRuntimeException:
> > org.libvirt.LibvirtException: invalid argument: can't shrink capacity
> below
> > existing allocation
> > at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> > VolumeApiServiceImpl.java:1213)
> > at
> com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> > VolumeApiServiceImpl.java:2920)
> > at sun.reflect.GeneratedMethodAccessor1400.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(
> > VmWorkJobHandlerProxy.java:107)
> > at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(
> > VolumeApiServiceImpl.java:2944)
> > at sun.reflect.GeneratedMethodAccessor1396.invoke(Unknown Source)
> > at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> > DelegatingMethodAccessorImpl.java:43)
> > at java.lang.reflect.Method.invoke(Method.java:606)
> > at org.springframework.aop.support.AopUtils.
> > invokeJoinpointUsingReflection(AopUtils.java:317)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > proceed(ReflectiveMethodInvocation.java:150)
> > at org.springframework.aop.interceptor.
> > ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> > at org.springframework.aop.framework.ReflectiveMethodInvocation.
> > proceed(ReflectiveMethodInvocation.java:172)
> > at org.springframework.aop.framework.JdkDynamicAopProxy.
> > invoke(JdkDynamicAopProxy.java:204)
> > at com.sun.proxy.$Proxy194.handleVmWorkJob(Unknown Source)
> > at com.cloud.vm.VmWorkJobDispatcher.runJob(
> > VmWorkJobDispatcher.java:102)
> > at org.apache.cloudstack.framework.jobs.impl.
> > AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> > 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 org.apache.cloudstack.framework.jobs.impl.
> > AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> > at java.util.concurrent.Executors$RunnableAdapter.
> > call(Executors.java:471)
> > at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> > at java.util.concurrent.ThreadPoolExecutor.runWorker(
> > ThreadPoolExecutor.java:1145)
> > at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> > ThreadPoolExecutor.java:615)
> > at java.lang.Thread.run(Thread.java:745)
> > 2018-08-16 17:52:31,543 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> > (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Complete
> > async job-69196, jobStatus: FAILED, resultCode: 530, result:
> > org.apache.cloudstack.api.response.Except
> >
> ionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"org.libvirt.LibvirtException:
> > invalid argument: can\u0027t shrink capacity below existing allocation"}
> > ====
> >
> > On the hypervisor host's CloudStack agent log:
> >
> > ====
> > 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Request:Seq 76-5194057745242603743: { Cmd
> ,
> > MgmtId: 14038008226984, via: 76, Ver: v1, Flags: 100011,
> > [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"p
> > ath":"0de865cf-cbd1-4b7b-8052-929ea7ebfc80","pool":{"id":
> > 214,"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","host":"
> > xxxx-yyy.xxxxxxxxx.com","path":"xxxxxxxxx-yy-88","userInfo":"admin:
> > xxxxxxxxxxxxxx","port":
> > 6789,"type":"RBD"},"vmInstance":"i-3149-5290-VM","newSize":21474836480,"
> > currentSize":42949672960,"shrinkOk":true,"wait":0}}] }
> > 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Processing command:
> > com.cloud.agent.api.storage.ResizeVolumeCommand
> > 2018-08-16 17:52:29,790 INFO [kvm.storage.LibvirtStorageAdaptor]
> > (agentRequest-Handler-2:null) Trying to fetch storage pool
> > d433809b-01ea-3947-ba0f-48077244e4d6 from libvirt
> > 2018-08-16 17:52:29,790 DEBUG [kvm.resource.LibvirtConnection]
> > (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> > qemu:///system
> > 2018-08-16 17:52:29,794 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> > (agentRequest-Handler-2:null) Succesfully refreshed pool
> > d433809b-01ea-3947-ba0f-48077244e4d6 Capacity: 68604993286144 Used:
> > 17779163430778 Available: 32956092846080
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> > xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 is on a RBD storage
> > pool. No need to query for additional inf
> > ormation.
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Resizing
> > volume: xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80,
> > 42949672960,21474836480,NOTIFYONLY,i-3149-5290-VM,t
> > rue
> > 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> > LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> > xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 can be resized by
> > libvirt. Asking libvirt to resize the volum
> > e.
> > 2018-08-16 17:52:30,002 DEBUG [kvm.resource.LibvirtConnection]
> > (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> > qemu:///system
> > 2018-08-16 17:52:30,003 DEBUG [cloud.agent.Agent]
> > (agentRequest-Handler-2:null) Seq 76-5194057745242603743: { Ans: ,
> MgmtId:
> > 14038008226984, via: 76, Ver: v1, Flags: 10, [{"com.cloud.agent.api.
> > storage.ResizeVolumeAnswer":{"newSize":0,"r
> > esult":false,"details":"org.libvirt.LibvirtException: invalid argument:
> > can't shrink capacity below existing allocation","wait":0}}] }
> > ====
> >
> > On the libvirtd.log:
> >
> > ====
> > 2018-08-16 09:52:30.003+0000: 3599: error : storageVolResize:2164 :
> > invalid argument: can't shrink capacity below existing allocation
> > ====
> >
> > We are using libvirtd (libvirt) 1.2.3. Not too sure if it's the issue
> with
> > the libvirt version we are using?
> >
> > Not too sure what existing allocation it refers to, is there any settings
> > under CloudStack related to this?
> >
> > Resizing up a disk works fine, only resizing down will have this problem.
> >
> > Anyone encountered this problem before? Any advice is greatly
> appreciated.
> >
> > Looking forward to your reply, thank you.
> >
> > Cheers.
> >
>
Re: Unable to resize down data disk: libvirt exception - invalid
argument: can't shrink capacity below existing allocation
Posted by Simon Weller <sw...@ena.com.INVALID>.
This looks like a libvirt limitation/bug. What OS are you using?
________________________________
From: Cloud List <cl...@sg.or.id>
Sent: Tuesday, September 18, 2018 11:34 PM
To: users@cloudstack.apache.org
Subject: Re: Unable to resize down data disk: libvirt exception - invalid argument: can't shrink capacity below existing allocation
Hi,
Anyone can advise on below? Or is it confirmed that resizing down
(shrinking) the data-disk is no longer supported on CloudStack with KVM,
libvirt and Ceph RBD storage?
Looking forward to your reply, thank you.
Cheers.
On Thu, Aug 16, 2018 at 6:07 PM, Cloud List <cl...@sg.or.id> wrote:
> Hi,
>
> We are using CloudStack 4.8.1.1 with QEMU/KVM hypervisor, libvirt and Ceph
> RBD storage.
>
> We just realised that we are not able to resize down any of our
> data-disks, and we are sure that we were able to do that before. Not too
> sure since when the problem started to happen.
>
> When we tried to resize a data disk of a VM on CloudStack admin panel by
> stopping the VM and then go to Instance > VM hostname > View Volumes >
> DATA-XXXX > Resize volume > Select a disk offering with lower storage size
> > Tick on "Shrink OK" > click OK, we get this error messages as a pop-up on
> the CloudStack admin panel:
>
> ====
> org.libvirt.LibvirtException: invalid argument: can't shrink capacity
> below existing allocation
> ====
>
> On management server logs:
>
> ====
> 2018-08-16 17:52:31,541 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Unexpected
> exception while executing org.apache.cloudstack.api.command.admin.volume.
> ResizeVolumeCmdByAdmin
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: invalid argument: can't shrink capacity below
> existing allocation
> at com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> VolumeApiServiceImpl.java:1213)
> at com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> VolumeApiServiceImpl.java:2920)
> at sun.reflect.GeneratedMethodAccessor1400.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(
> VmWorkJobHandlerProxy.java:107)
> at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(
> VolumeApiServiceImpl.java:2944)
> at sun.reflect.GeneratedMethodAccessor1396.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:172)
> at org.springframework.aop.framework.JdkDynamicAopProxy.
> invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy194.handleVmWorkJob(Unknown Source)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(
> VmWorkJobDispatcher.java:102)
> at org.apache.cloudstack.framework.jobs.impl.
> AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> 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 org.apache.cloudstack.framework.jobs.impl.
> AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2018-08-16 17:52:31,543 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Complete
> async job-69196, jobStatus: FAILED, resultCode: 530, result:
> org.apache.cloudstack.api.response.Except
> ionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"org.libvirt.LibvirtException:
> invalid argument: can\u0027t shrink capacity below existing allocation"}
> ====
>
> On the hypervisor host's CloudStack agent log:
>
> ====
> 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 76-5194057745242603743: { Cmd ,
> MgmtId: 14038008226984, via: 76, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"p
> ath":"0de865cf-cbd1-4b7b-8052-929ea7ebfc80","pool":{"id":
> 214,"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","host":"
> xxxx-yyy.xxxxxxxxx.com","path":"xxxxxxxxx-yy-88","userInfo":"admin:
> xxxxxxxxxxxxxx","port":
> 6789,"type":"RBD"},"vmInstance":"i-3149-5290-VM","newSize":21474836480,"
> currentSize":42949672960,"shrinkOk":true,"wait":0}}] }
> 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.storage.ResizeVolumeCommand
> 2018-08-16 17:52:29,790 INFO [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-2:null) Trying to fetch storage pool
> d433809b-01ea-3947-ba0f-48077244e4d6 from libvirt
> 2018-08-16 17:52:29,790 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> qemu:///system
> 2018-08-16 17:52:29,794 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-2:null) Succesfully refreshed pool
> d433809b-01ea-3947-ba0f-48077244e4d6 Capacity: 68604993286144 Used:
> 17779163430778 Available: 32956092846080
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 is on a RBD storage
> pool. No need to query for additional inf
> ormation.
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Resizing
> volume: xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80,
> 42949672960,21474836480,NOTIFYONLY,i-3149-5290-VM,t
> rue
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 can be resized by
> libvirt. Asking libvirt to resize the volum
> e.
> 2018-08-16 17:52:30,002 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> qemu:///system
> 2018-08-16 17:52:30,003 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 76-5194057745242603743: { Ans: , MgmtId:
> 14038008226984, via: 76, Ver: v1, Flags: 10, [{"com.cloud.agent.api.
> storage.ResizeVolumeAnswer":{"newSize":0,"r
> esult":false,"details":"org.libvirt.LibvirtException: invalid argument:
> can't shrink capacity below existing allocation","wait":0}}] }
> ====
>
> On the libvirtd.log:
>
> ====
> 2018-08-16 09:52:30.003+0000: 3599: error : storageVolResize:2164 :
> invalid argument: can't shrink capacity below existing allocation
> ====
>
> We are using libvirtd (libvirt) 1.2.3. Not too sure if it's the issue with
> the libvirt version we are using?
>
> Not too sure what existing allocation it refers to, is there any settings
> under CloudStack related to this?
>
> Resizing up a disk works fine, only resizing down will have this problem.
>
> Anyone encountered this problem before? Any advice is greatly appreciated.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
Re: Unable to resize down data disk: libvirt exception - invalid
argument: can't shrink capacity below existing allocation
Posted by Cloud List <cl...@sg.or.id>.
Hi,
Anyone can advise on below? Or is it confirmed that resizing down
(shrinking) the data-disk is no longer supported on CloudStack with KVM,
libvirt and Ceph RBD storage?
Looking forward to your reply, thank you.
Cheers.
On Thu, Aug 16, 2018 at 6:07 PM, Cloud List <cl...@sg.or.id> wrote:
> Hi,
>
> We are using CloudStack 4.8.1.1 with QEMU/KVM hypervisor, libvirt and Ceph
> RBD storage.
>
> We just realised that we are not able to resize down any of our
> data-disks, and we are sure that we were able to do that before. Not too
> sure since when the problem started to happen.
>
> When we tried to resize a data disk of a VM on CloudStack admin panel by
> stopping the VM and then go to Instance > VM hostname > View Volumes >
> DATA-XXXX > Resize volume > Select a disk offering with lower storage size
> > Tick on "Shrink OK" > click OK, we get this error messages as a pop-up on
> the CloudStack admin panel:
>
> ====
> org.libvirt.LibvirtException: invalid argument: can't shrink capacity
> below existing allocation
> ====
>
> On management server logs:
>
> ====
> 2018-08-16 17:52:31,541 ERROR [c.c.a.ApiAsyncJobDispatcher]
> (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Unexpected
> exception while executing org.apache.cloudstack.api.command.admin.volume.
> ResizeVolumeCmdByAdmin
> com.cloud.utils.exception.CloudRuntimeException:
> org.libvirt.LibvirtException: invalid argument: can't shrink capacity below
> existing allocation
> at com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> VolumeApiServiceImpl.java:1213)
> at com.cloud.storage.VolumeApiServiceImpl.orchestrateResizeVolume(
> VolumeApiServiceImpl.java:2920)
> at sun.reflect.GeneratedMethodAccessor1400.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(
> VmWorkJobHandlerProxy.java:107)
> at com.cloud.storage.VolumeApiServiceImpl.handleVmWorkJob(
> VolumeApiServiceImpl.java:2944)
> at sun.reflect.GeneratedMethodAccessor1396.invoke(Unknown Source)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(
> DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.springframework.aop.support.AopUtils.
> invokeJoinpointUsingReflection(AopUtils.java:317)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> invokeJoinpoint(ReflectiveMethodInvocation.java:183)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:150)
> at org.springframework.aop.interceptor.
> ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:91)
> at org.springframework.aop.framework.ReflectiveMethodInvocation.
> proceed(ReflectiveMethodInvocation.java:172)
> at org.springframework.aop.framework.JdkDynamicAopProxy.
> invoke(JdkDynamicAopProxy.java:204)
> at com.sun.proxy.$Proxy194.handleVmWorkJob(Unknown Source)
> at com.cloud.vm.VmWorkJobDispatcher.runJob(
> VmWorkJobDispatcher.java:102)
> at org.apache.cloudstack.framework.jobs.impl.
> AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:554)
> 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 org.apache.cloudstack.framework.jobs.impl.
> AsyncJobManagerImpl$5.run(AsyncJobManagerImpl.java:502)
> at java.util.concurrent.Executors$RunnableAdapter.
> call(Executors.java:471)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(
> ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(
> ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:745)
> 2018-08-16 17:52:31,543 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
> (API-Job-Executor-99:ctx-1392adbe job-69196) (logid:2f71074c) Complete
> async job-69196, jobStatus: FAILED, resultCode: 530, result:
> org.apache.cloudstack.api.response.Except
> ionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"org.libvirt.LibvirtException:
> invalid argument: can\u0027t shrink capacity below existing allocation"}
> ====
>
> On the hypervisor host's CloudStack agent log:
>
> ====
> 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Request:Seq 76-5194057745242603743: { Cmd ,
> MgmtId: 14038008226984, via: 76, Ver: v1, Flags: 100011,
> [{"com.cloud.agent.api.storage.ResizeVolumeCommand":{"p
> ath":"0de865cf-cbd1-4b7b-8052-929ea7ebfc80","pool":{"id":
> 214,"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","host":"
> xxxx-yyy.xxxxxxxxx.com","path":"xxxxxxxxx-yy-88","userInfo":"admin:
> xxxxxxxxxxxxxx","port":
> 6789,"type":"RBD"},"vmInstance":"i-3149-5290-VM","newSize":21474836480,"
> currentSize":42949672960,"shrinkOk":true,"wait":0}}] }
> 2018-08-16 17:52:29,790 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Processing command:
> com.cloud.agent.api.storage.ResizeVolumeCommand
> 2018-08-16 17:52:29,790 INFO [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-2:null) Trying to fetch storage pool
> d433809b-01ea-3947-ba0f-48077244e4d6 from libvirt
> 2018-08-16 17:52:29,790 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> qemu:///system
> 2018-08-16 17:52:29,794 DEBUG [kvm.storage.LibvirtStorageAdaptor]
> (agentRequest-Handler-2:null) Succesfully refreshed pool
> d433809b-01ea-3947-ba0f-48077244e4d6 Capacity: 68604993286144 Used:
> 17779163430778 Available: 32956092846080
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 is on a RBD storage
> pool. No need to query for additional inf
> ormation.
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Resizing
> volume: xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80,
> 42949672960,21474836480,NOTIFYONLY,i-3149-5290-VM,t
> rue
> 2018-08-16 17:52:30,002 DEBUG [resource.wrapper.
> LibvirtResizeVolumeCommandWrapper] (agentRequest-Handler-2:null) Volume
> xxxxxxxxx-yy-88/0de865cf-cbd1-4b7b-8052-929ea7ebfc80 can be resized by
> libvirt. Asking libvirt to resize the volum
> e.
> 2018-08-16 17:52:30,002 DEBUG [kvm.resource.LibvirtConnection]
> (agentRequest-Handler-2:null) Looking for libvirtd connection at:
> qemu:///system
> 2018-08-16 17:52:30,003 DEBUG [cloud.agent.Agent]
> (agentRequest-Handler-2:null) Seq 76-5194057745242603743: { Ans: , MgmtId:
> 14038008226984, via: 76, Ver: v1, Flags: 10, [{"com.cloud.agent.api.
> storage.ResizeVolumeAnswer":{"newSize":0,"r
> esult":false,"details":"org.libvirt.LibvirtException: invalid argument:
> can't shrink capacity below existing allocation","wait":0}}] }
> ====
>
> On the libvirtd.log:
>
> ====
> 2018-08-16 09:52:30.003+0000: 3599: error : storageVolResize:2164 :
> invalid argument: can't shrink capacity below existing allocation
> ====
>
> We are using libvirtd (libvirt) 1.2.3. Not too sure if it's the issue with
> the libvirt version we are using?
>
> Not too sure what existing allocation it refers to, is there any settings
> under CloudStack related to this?
>
> Resizing up a disk works fine, only resizing down will have this problem.
>
> Anyone encountered this problem before? Any advice is greatly appreciated.
>
> Looking forward to your reply, thank you.
>
> Cheers.
>