cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zack <zpay...@gmail.com>
Subject Re: 4.3 systemvm's are really 4.2?
Date Wed, 28 May 2014 17:31:27 GMT
I think that rather than using the cloud-install-sys-tmplt command, it's recommended to use
the web UI as documented in the 4.3 release notes upgrade from 4.2.x to 4.3 section.

Z

> On May 28, 2014, at 9:19 AM, Derek Page <dpage@kayak.com> wrote:
> 
> From a fresh install of cloudstack 4.3 and installing the 4.3 system vms
> from download.cloud.com
> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2
> 
> If you look at the system vms their /etc/cloudstack-version is still 4.2
> root@r-21-VM:~# cat /etc/cloudstack-release
> Cloudstack Release 4.2.0 Tue Jul 16 04:16:55 UTC 2013
> 
> 
> This was causing a failure to deploy instances with the following stack
> trace.
> 
> Caused by: com.cloud.exception.AgentUnavailableException: Resource [Host:5]
> is unreachable: Host 5: Unable to start instance due to Unable to send
> command. Upgrade in progress. Please contact administrator.
>    at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:1072)
>    at
> com.cloud.vm.VirtualMachineManagerImpl.advanceStart(VirtualMachineManagerImpl.java:761)
>    at
> com.cloud.vm.VirtualMachineManagerImpl.start(VirtualMachineManagerImpl.java:601)
>    ... 37 more
> Caused by: com.cloud.utils.exception.CloudRuntimeException: Unable to send
> command. Upgrade in progress. Please contact administrator.
>    at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.sendCommandsToRouter(VirtualNetworkApplianceManagerImpl.java:3616)
>    at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute(VirtualNetworkApplianceManagerImpl.java:3051)
>    at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyRules(VirtualNetworkApplianceManagerImpl.java:3903)
>    at
> com.cloud.network.router.VirtualNetworkApplianceManagerImpl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:3043)
>    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
>    at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
>    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.$Proxy240.applyDhcpEntry(Unknown Source)
>    at
> com.cloud.network.element.VirtualRouterElement.addDhcpEntry(VirtualRouterElement.java:921)
>    at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareElement(NetworkOrchestrator.java:1187)
>    at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepareNic(NetworkOrchestrator.java:1309)
>    at
> org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.prepare(NetworkOrchestrator.java:1245)
>    at
> com.cloud.vm.VirtualMachineManagerImpl.orchestrateStart(VirtualMachineManagerImpl.java:960)
>    ... 39 more
> 
> 
> So from here I.
> Destroyed/Expunged all systemvm's
> Removed the secondary storage in cloudstack
> rm -fr /mnt/secondary/*
> recreated the secondary storage in cloudstack
> Pulled the systemvms back down using this command:
> $ sudo
> /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt
> -m /secondary -u
> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2-h
> xenserver -F
> 
> But still the systemvm's are at version 4.2
> 
> Next I manually hacked /etc/cloudstack-version to be 4.3 instead of 4.2 on
> the router and I was able to deploy instances.
> This is my only work around at the moment.
> 
> Is there a later version of the system VM's?
> Or did someone forget to bump versions in /etc/cloudstack-version?
> Or am I completely doing something wrong?
> 
> -- 
> Derek Page
> Operations Engineer
> KAYAK

Mime
View raw message