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.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
