Hi Indra, Which hypervisor are you using?
Thanks and regards, Abhinav -----Original Message----- From: Indra Pramana [mailto:in...@sg.or.id] Sent: Wednesday, September 25, 2013 9:18 PM To: d...@cloudstack.apache.org Cc: users@cloudstack.apache.org Subject: Re: Upgrade failed because system VM was created using old template? Hi Abhinav, Good day to you, and thank you for your e-mail. Noted, thanks for confirming that the json deserialization error is expected during the upgrade. The issue that I had was that the cloudstack-sysvmadm command fails to run. Here is the content of the sysvm.log file after I run the command: nohup cloudstack-sysvmadm -d 10.237.1.3 -u cloud -p92dhWStn -a > sysvm.log 2>&1 & === nohup: ignoring input /usr/bin/cloudstack-sysvmadm: line 21: /etc/rc.d/init.d/functions: No such file or directory Stopping and starting 1 secondary storage vm(s)... Done stopping and starting secondary storage vm(s) Stopping and starting 1 console proxy vm(s)... ERROR: Failed to start console proxy vm with id 1903 Done stopping and starting console proxy vm(s) . Stopping and starting 2 running routing vm(s)... ERROR: Failed to restart domainRouter with id 1931 ERROR: Failed to restart domainRouter with id 1930 Done restarting router(s). === What could be the reason on why the script fails to restart the CPVM and the two VRs? It seems to be successfully restarted the SSVM though. But still, the SSVM was on "Starting" state and never started. I will upload the management logs and will send the URL to you separately. Thank you. On Wed, Sep 25, 2013 at 8:37 PM, Abhinav Roy <abhinav....@citrix.com> wrote: > Hi Indra, > > The Json deserialization error is an expected one, after you upgrade. > It ll keep coming until the new systemvms come up using the new > systemvvm template. > All the steps you have executed are correct and you don't need to > change those. > > As soon as you upgrade and start management server, you will see Json > deserialization error, that is expected. > After that when you run the cloudstack-sysvmadm command the new > systemvms using the new templates will come up and you won't see that error > anymore. > Are they not coming up even after running cloudstack-sysvmadm command?? > Can you copy the full management server log somewhere so that I can > have a look? > > Thanks and regards, > Abhinav > > -----Original Message----- > From: Indra Pramana [mailto:in...@sg.or.id] > Sent: Wednesday, September 25, 2013 5:11 PM > To: d...@cloudstack.apache.org; users@cloudstack.apache.org > Subject: Upgrade failed because system VM was created using old template? > > Dear all, > > I scrutinized the CloudStack management logs during my failed upgrade > attempt from CloudStack 4.1.1 to 4.2.0 and found this on the log: > > === > 2013-09-24 02:53:56,029 DEBUG [cloud.storage.VolumeManagerImpl] > (secstorage-1:null) Checking if we need to prepare 1 volumes for > VM[SecondaryStorageVm|s-1979-VM] > 2013-09-24 02:53:56,044 DEBUG [storage.image.TemplateDataFactoryImpl] > (secstorage-1:null) template 3 is already in store:27, type:Image > 2013-09-24 02:53:56,069 DEBUG [storage.datastore.PrimaryDataStoreImpl] > (secstorage-1:null) Not found (templateId:3poolId:214) in > template_spool_ref, persisting it > 2013-09-24 02:53:56,092 DEBUG [storage.image.TemplateDataFactoryImpl] > (secstorage-1:null) template 3 is already in store:214, type:Primary > 2013-09-24 02:53:56,095 DEBUG [storage.volume.VolumeServiceImpl] > (secstorage-1:null) Found template routing-3 in storage pool 214 with > VMTemplateStoragePool id: 76 > 2013-09-24 02:53:56,105 DEBUG [storage.volume.VolumeServiceImpl] > (secstorage-1:null) Acquire lock on VMTemplateStoragePool 76 with > timeout > 3600 seconds > 2013-09-24 02:53:56,113 INFO [storage.volume.VolumeServiceImpl] > (secstorage-1:null) lock is acquired for VMTemplateStoragePool 76 > 2013-09-24 02:53:56,141 DEBUG > [storage.motion.AncientDataMotionStrategy] > (secstorage-1:null) copyAsync inspecting src type TEMPLATE copyAsync > inspecting dest type TEMPLATE > 2013-09-24 02:53:56,168 DEBUG [agent.transport.Request] > (secstorage-1:null) Seq 37-1888026692: Sending { Cmd , MgmtId: > 161342671900, via: 37, Ver: v1, > Flags: 100111, [ > > {"org.apache.cloudstack.storage.command.CopyCommand":{"srcTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"path":"template/tmpl/1/3//425b9e5a-fbc7-4637-a33a-fe9d0ed4fa98.qcow2","origUrl":" > http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow > 2.bz2 ","uuid":"396d8a45-ea18-11e2-8050-6e875929c251","id":3,"format" > > :"QCOW2","accountId":1,"checksum":"2755de1f9ef2ce4d6f2bee2efbb4da92"," > hvm":false,"displayText":"SystemVM > Template > (KVM)","imageDataStore":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs:/ > / > 10.237.11.31/mnt/vol1/sec-storage > > ","_role":"Image"}},"name":"routing-3","hypervisorType":"KVM"}},"destTO":{"org.apache.cloudstack.storage.to.TemplateObjectTO":{"origUrl":" > http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow > 2.bz2 > ","uuid":"396d8a45-ea18-11e2-8050-6e875929c251","id":3,"format":"QCOW2 > ","accountId":1,"checksum":"2755de1f9ef2ce4d6f2bee2efbb4da92","hvm":fa > lse,"displayText":"SystemVM > Template > > (KVM)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryData > StoreTO":{"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","id":214,"pool > Type":"RBD","host":"xxx","path":"xxx","port":6789}},"name":"routing-3" > ,"hypervisorType":"KVM"}},"executeInSequence":true,"wait":10800}}] > } > === > > It seems that after the upgrade, the CloudStack management server > tries to create the system VMs using the old template rather than the > new 4.2 template. > > I did use the wrong filename when registering the template > (systemvm-kvm-4.2.0 instead of systemvm-kvm-4.2) due to wrong > information given by Abhinav but I have since corrected it prior to > the upgrade, by renaming the template name (rather than deleting the > template and re-register it). > > My questions: > > 1. Do I need to get the template name right when I register the > systemvm-kvm-4.2 template from the beginning, prior to the upgrade? > > 2. Do I need to delete the old system VM template from the template > list, prior to the upgrade? If yes, I think this should be inside the > documentation. > > Looking forward to your reply, thank you. > > Cheers. >
