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.qcow2.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.qcow2.bz2","uuid":"396d8a45-ea18-11e2-8050-6e875929c251","id":3,"format":"QCOW2","accountId":1,"checksum":"2755de1f9ef2ce4d6f2bee2efbb4da92","hvm":false,"displayText":"SystemVM Template (KVM)","imageDataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"d433809b-01ea-3947-ba0f-48077244e4d6","id":214,"poolType":"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.
