cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrei Mikhailovsky <and...@arhont.com.INVALID>
Subject 4.11.0 - can't create guest vms with RBD storage!
Date Mon, 30 Apr 2018 13:14:19 GMT
hello gents, 

I have just realised that after upgrading to 4.11.0 we are no longer able to create new VMs.
This has just been noticed as we have previously used ready made templates, which work just
fine. 

Setup: ACS 4.11.0 (upgraded from 4.9.3), KVM + CEPH, Ubuntu 16.04 on all servers 

When trying to create a new vm from an ISO image I get the following error: 


com.cloud.exception.StorageUnavailableException: Resource [StoragePool:2] is unreachable:
Unable to create Vol[3937|vm=2217|ROOT]:com.cloud.utils.exception.CloudRuntimeException: org.libvirt.LibvirtException:
this function is not supported by the connection driver: only RAW volumes are supported by
this storage pool 

at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.recreateVolume(VolumeOrchestrator.java:1336)

at org.apache.cloudstack.engine.orchestration.VolumeOrchestrator.prepare(VolumeOrchestrator.java:1413)

at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1110)

at com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:4927)

at sun.reflect.GeneratedMethodAccessor498.invoke(Unknown Source) 
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) 
at java.lang.reflect.Method.invoke(Method.java:498) 
at com.cloud.vm.VmWorkJobHandlerProxy.handleVmWorkJob(VmWorkJobHandlerProxy.java:107) 
at com.cloud.vm.VirtualMachineManagerImpl.handleVmWorkJob(VirtualMachineManagerImpl.java:5090)

at com.cloud.vm.VmWorkJobDispatcher.runJob(VmWorkJobDispatcher.java:102) 
at org.apache.cloudstack.framework.jobs.impl.AsyncJobManagerImpl$5.runInContext(AsyncJobManagerImpl.java:581)

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:529)

at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511) 
at java.util.concurrent.FutureTask.run(FutureTask.java:266) 
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) 
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) 
at java.lang.Thread.run(Thread.java:748) 


My guess is that ACS tried to create a QCOW2 image type whereas it should be RAW on ceph/rbd.


I am really struggling to understand how this bug in a function of MAJOR importance could
have been missed during the tests ran by developers and community before making a final realise.
Anyways, I hope the fix will make it to 4.11.1 release, otherwise it's really messed up! 

Cheers 

Andrei 

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message