cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Abhinav Roy <abhinav....@citrix.com>
Subject RE: Upgrade failed because system VM was created using old template?
Date Wed, 25 Sep 2013 12:37:17 GMT
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:indra@sg.or.id] 
Sent: Wednesday, September 25, 2013 5:11 PM
To: dev@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.

Mime
View raw message