Hello, Try this link, these templates even remediate the heartbleed vulnerability
http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm64/ Kind Regards Amin -----Original Message----- From: Derek Page [mailto:[email protected]] Sent: Thursday, 29 May 2014 12:19 AM To: [email protected] Subject: 4.3 systemvm's are really 4.2? >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
