Don¹t understand problem well enough for clean fix, but I updated 'template_version' from 3.0 to 4.3 of the VR in the domain_router table that resolved the issue for me.
On 22/11/13 3:50 PM, "Will Stevens" <wstev...@cloudops.com> wrote: >Has anyone been able to resolve this issue? This is holding up my ability >to launch VMs and test the fixes to my plugin. I need to resolve this >issue to move forward... > >@Syed, are you still stuck on this as well? > >Cheers, > >Will > > >On Wed, Nov 20, 2013 at 5:18 PM, Syed Ahmed <sah...@cloudops.com> wrote: > >> OK here is how far I got debugging this. I think I am missing a small >> thing. I hope you guys can help. >> >> So my VM template has the correct version. >> >> root@eng-ns-dev-cs1: /export/secondary/template/tmpl/1/1 # strings >> f3fc75d9-0240-4c71-a3bf-fb65652e4763.vhd | grep Cloudstack >> >> Cloudstack Release* 4.2.0*Tue Nov 19 23:22:37 UTC 2013 >> >> >> But in the database I see the following ( table domain_router ) >> >> *************************** 4. row *************************** >> id: 11 >> element_id: 4 >> public_mac_address: 06:48:a8:00:00:68 >> public_ip_address: 172.30.91.102 >> public_netmask: 255.255.255.0 >> guest_netmask: NULL >> guest_ip_address: NULL >> is_redundant_router: 0 >> priority: 0 >> is_priority_bumpup: 0 >> redundant_state: UNKNOWN >> stop_pending: 0 >> role: VIRTUAL_ROUTER >> template_version:*Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012* >> scripts_version: 725d5e5901a62c68aed0dd3463023518 >> vpc_id: NULL >> 4 rows in set (0.00 sec) >> >> >> >> I guess this is populated from the VM that gets created. On the xen the >>vm >> is r-11. I see the following version on that VM >> >> root@r-11-VM:~# cat /etc/cloudstack-release >> Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012 >> >> >> This means that Xen is not picking up the template present in the >> secondary storage. Does Xen cache the vhd files locally to avoid coming >>to >> the secondary storage? If so, how can I disable that? >> >> Also, I was looking at UpgradeRouterTemplateCmd API which basically goes >> through all the VRs and reboots them. It expects that when the reboot is >> completed, the router should have picked up the 4.2.0 version of the >> template ( see line 4072 in VirtualNetworkApplianceManagerImpl.java ) I >> try to do the reboot manually but the template remains the same. Do you >> guys have any more suggestions? >> >> Thanks, >> -Syed >> >> >> >> >> >> >> On Wed 20 Nov 2013 12:55:04 PM EST, Wei ZHOU wrote: >> >>> >>> FYI. >>> >>> I upgraded from 2.2.14 to 4.2.1. The CPVM, SSVM and VRs are working >>>after >>> running *cloudstack-sysvmadm to recreate.* >>> >>> >>> 2013/11/20 Syed Ahmed <sah...@cloudops.com> >>> >>> >>>> +1 Same error. The secondary storage VM and the Console proxy VM seem >>>>to >>>> be coming up alright. I see this error only when starting the virtual >>>> router which is preventing me from creating any instances. >>>> >>>> >>>> On Wed 20 Nov 2013 11:14:47 AM EST, Will Stevens wrote: >>>> >>>> >>>>> I am having the same problem. I got the latest system VMs from: >>>>> http://jenkins.buildacloud.org/view/master/job/build-systemvm-master/ >>>>> lastSuccessfulBuild/artifact/tools/appliance/dist/ >>>>> >>>>> Are these the wrong System VM Templates? If so, where should I get >>>>>the >>>>> System VM Templates to make this work again? >>>>> >>>>> Thanks, >>>>> >>>>> Will >>>>> >>>>> >>>>> On Thu, Nov 7, 2013 at 7:42 PM, Alena Prokharchyk < >>>>> alena.prokharc...@citrix.com> wrote: >>>>> >>>>> Nitin, I had the same problem, but I fixed it by uploading 4.2 system >>>>> >>>>>> >>>>>> templates to my secondary storage. Make sure you have the latest >>>>>>too. >>>>>> >>>>>> -alena. >>>>>> >>>>>> From: Nitin Mehta <nitin.me...@citrix.com<mailto: >>>>>> nitin.me...@citrix.com> >>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> Reply-To: >>>>>>"dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org >>>>>> >" >>>>>> < >>>>>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> >>>>>> Date: Thursday, November 7, 2013 4:16 PM >>>>>> To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" < >>>>>> dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> >>>>>> Subject: Router requires upgrade. Unable to send command to router >>>>>> Error >>>>>> >>>>>> Unable to deploy vms in the latest master because of the commit >>>>>>below. >>>>>> Is >>>>>> anyone noticing this on the latest master. >>>>>> I checked the code and there was a commit made recently 3f5b8f >>>>>>which is >>>>>> where the exception points to. >>>>>> >>>>>> WARN [o.a.c.alerts] (CapacityChecker:ctx-4f1ef01f) alertType:: 2 // >>>>>> dataCenterId:: 3 // podId:: 3 // clusterId:: null // message:: >>>>>>System >>>>>> Alert: Low Available Storage in cluster c3 pod p of availability >>>>>>zone >>>>>> z3 >>>>>> INFO [o.a.c.f.j.i.AsyncJobMonitor] (Job-Executor-1:ctx-f118d6dc) Add >>>>>> job-44 into job monitoring >>>>>> WARN [c.c.h.x.r.CitrixResourceBase] (DirectAgent-26:ctx-3e786331) >>>>>> Detecting a change in xstoolsversion for r-6-VM >>>>>> ERROR [c.c.v.VirtualMachineManagerImpl] (Job-Executor-1:ctx-f118d6dc >>>>>> ctx-d9a00f18) Failed to start instance >>>>>> VM[User|VM-4d5d5db2-e5ba-4bbd-b1dc-e749ac42a74c] >>>>>> com.cloud.utils.exception.CloudRuntimeException: Router requires >>>>>> upgrade. >>>>>> Unable to send command to router:6 >>>>>> at >>>>>> com.cloud.network.router.VirtualNetworkApplianceManager >>>>>> Impl.sendCommandsToRouter(VirtualNetworkApplianceManager >>>>>> Impl.java:3567) >>>>>> at >>>>>> >>>>>>com.cloud.network.router.VirtualNetworkApplianceManagerImpl$7.execute >>>>>>( >>>>>> VirtualNetworkApplianceManagerImpl.java:3003) >>>>>> at >>>>>> com.cloud.network.router.VirtualNetworkApplianceManager >>>>>> Impl.applyRules( >>>>>> VirtualNetworkApplianceManagerImpl.java:3848) >>>>>> at >>>>>> com.cloud.network.router.VirtualNetworkApplianceManager >>>>>> Impl.applyDhcpEntry(VirtualNetworkApplianceManagerImpl.java:2995) >>>>>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at >>>>>> sun.reflect.NativeMethodAccessorImpl.invoke( >>>>>> NativeMethodAccessorImpl.java:39) >>>>>> at >>>>>> sun.reflect.DelegatingMethodAccessorImpl.invoke( >>>>>> DelegatingMethodAccessorImpl.java:25) >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>> >>>> >>>> >>> >>> >> >> >
