That's true. I am just so used to grabbing 64bit distros that it did not cross my mind.
Thanks for the suggestion. On May 29, 2014 6:44 PM, "ilya musayev" <[email protected]> wrote: > Interesting, i've done the same thing several times, i had no issues > you've mentioned. > > I'm not using 64bit router VMs though. The version of routervm on my 4.3 > test environment is 32bit 2014-04-09 (contains heartbleed patch). > > I pulled it from Jenkins. > > Unless you are going to allocate more than 4GB of RAM to your router VMs, > i'm not aware of any benefits of going with 64bit. > > On 5/29/14, 8:06 AM, Derek Page wrote: > >> Unfortunately pulling down the templates from Jenkins still did not help >> me. >> >> I tried to upgrade using the GUI method Clicking "Upgrade Router" button >> no >> luck. >> Also tried to upgrade using the method that Zack suggested from the >> release >> notes doc. >> Lastly tried to upgrade with cloud-install-sys-tmplt command using with >> Jenkins templates. >> >> Has anyone had luck with these methods? >> >> Since this is just a test instance of cloudstack and I don't really care >> about the data I went extreme. >> >> I disabled my zone. >> Destroyed systemvms and router >> Destroyed all templates >> Destroyed primary and secondary storage. >> rm -fr /secondary/* /primary/* >> Recreated primary and secondary storage >> Pulled down the Jenkins template with cloud-install-sys-tmplt and finally >> I >> am at 4.3 >> >> root@s-36-VM:~# cat /etc/cloudstack-release >> Cloudstack Release 4.3.0 (64-bit) Tue Apr 15 16:48:30 UTC 2014 >> >> I wish I had a better answer. >> Thanks for all your replys. >> >> >> On Wed, May 28, 2014 at 9:07 PM, Amin Samir <[email protected]> >> wrote: >> >> 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.VirtualNetworkApplianceManager >>> Impl.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.VirtualNetworkApplianceManager >>> Impl.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 >>> >>> >>> >> >
