4.11.0 - can't create guest vms with RBD storage!
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
Re: 4.11.0 - can't create guest vms with RBD storage!
We might need some extra log entries. Can you provide them? On Mon, Apr 30, 2018 at 10:14 AM, Andrei Mikhailovsky < and...@arhont.com.invalid> wrote: > 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 > -- Rafael Weingärtner
Re: 4.11.0 - can't create guest vms with RBD storage!
Agreed. agent.log might be helpful for troubleshooting. it seems to be a bug within kvm plugin. -Wei 2018-04-30 15:36 GMT+02:00 Rafael Weingärtner : > We might need some extra log entries. Can you provide them? > > On Mon, Apr 30, 2018 at 10:14 AM, Andrei Mikhailovsky < > and...@arhont.com.invalid> wrote: > > > 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 > > > > > > -- > Rafael Weingärtner >
Re: [NOTICE] Impending shutdown of download.cloud.com - this may affect your CloudStack installation
FINAL NOTICE download.cloud.com will be deleted permanently on May 4 2018 On Tue, Apr 10, 2018 at 11:13 AM, Chiradeep Vittal wrote: > I have not heard any complaints, although from the access logs I see lots > of attempts to download legacy templates. > download.cloud.com will remain offline until April 30. > On April 30 2018, download.cloud.com will be decommissioned permanently. > > On Fri, Mar 30, 2018 at 12:37 PM, Chiradeep Vittal > wrote: > >> download.cloud.com will go offline temporarily for a few days. If you >> need access to it, check the instructions below. If that doesn't work, >> reply on this thread. >> >> On Tue, Mar 20, 2018 at 11:44 AM, Chiradeep Vittal >> wrote: >> >>> On April 30, 2018, the domain download.cloud.com will be decommissioned. >>> >>> >>> THIS MAY AFFECT YOUR CLOUDSTACK INSTALLATION. PLEASE READ FURTHER. >>> >>> BACKGROUND >>> download.cloud.com was used to host the seed templates (images) for a >>> CloudStack installation. This included the system vm templates for releases >>> prior to 4.10. Around March 2017[1], a new site was established ( >>> download.cloudstack.org) and all the content (templates) was copied >>> over to the new site. From release 4.10 onwards[2][3], the seed templates >>> are fetched / downloaded from the new site during an installation of Apache >>> CloudStack. >>> >>> >>> To check if your CloudStack installation has a reference to the old site >>> (download.cloud.com), check your vm_template table: >>> >>> SELECT url FROM vm_template; >>> >>> WHO MAY BE AFFECTED >>> CloudStack operators installing a version of Apache CloudStack prior to >>> version 4.10 after the shutdown. An already running/functioning CloudStack >>> cloud will continue to operate with no disruption after the shutdown. >>> However, operations such as: adding a zone, backup and restore, secondary >>> storage backup/restore, etc may be affected. >>> >>> STEPS TO BE TAKEN TO AVOID IMPACT >>> Update the vm_template table to point to the new location: >>> >>> UPDATE vm_template SET url = REPLACE(url, 'download.cloud.com', ' >>> download.cloudstack.org'); >>> >>> TRIAL RUN OF THE SHUTDOWN >>> During the last week of March 2018, download.cloud.com will be taken >>> temporarily offline. This is to make sure that CloudStack operators who >>> have not paid attention to this notice but are affected, will pay attention. >>> >>> This notice will be posted periodically until the shutdown. >>> -- >>> Chiradeep >>> >>> [1] http://mail-archives.apache.org/mod_mbox/cloudstack-dev/ >>> 201703.mbox/%3c596136829.12220.1489142173...@ox.pcextreme.nl%3E >>> [2] https://github.com/apache/cloudstack/pull/1582 >>> [3] https://github.com/apache/cloudstack/commit/70ef0788c932 >>> f4de1060fd60025ce120f7da5be4 >>> >>> >> >
