cloudstack-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Indra Pramana <in...@sg.or.id>
Subject Upgrade failed because system VM was created using old template?
Date Wed, 25 Sep 2013 11:40:48 GMT
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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message