You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@cloudstack.apache.org by Indra Pramana <in...@sg.or.id> on 2013/09/25 13:40:48 UTC
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.
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Hi Abhinav,
Good day to you, and thank you for your e-mail reply.
If I remember correctly, at that time when I check the KVM hosts directly
by using "virsh list --all", the ssvm and cpvm are listed there and the
status is running. However, I can't SSH to the local link address.
It is a Ubuntu host.
Content of resource parameter under /etc/cloudstack/agent/agent.properties:
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
Thank you.
On Thu, Sep 26, 2013 at 12:19 AM, Abhinav Roy <ab...@citrix.com>wrote:
> Hi Indra,
>
> Can you check in your KVM host whether the ssvm and cpvm are created or
> not?
> try " virsh list " and see if the vms are there? Is it a Rhel host or
> Ubuntu host??
> Also, check what is the entry in /etc/cloudstack/agent/agent.properties
> file for the "resource" parameter.
>
> Thanks and regards,
> Abhinav
>
> -----Original Message-----
> From: Indra Pramana [mailto:indra@sg.or.id]
> Sent: Wednesday, September 25, 2013 9:32 PM
> To: users@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Upgrade failed because system VM was created using old
> template?
>
> Hi Abhinav,
>
> We are using KVM.
>
> Thank you.
>
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Hi Abhinav,
Good day to you, and thank you for your e-mail reply.
If I remember correctly, at that time when I check the KVM hosts directly
by using "virsh list --all", the ssvm and cpvm are listed there and the
status is running. However, I can't SSH to the local link address.
It is a Ubuntu host.
Content of resource parameter under /etc/cloudstack/agent/agent.properties:
resource=com.cloud.hypervisor.kvm.resource.LibvirtComputingResource
Thank you.
On Thu, Sep 26, 2013 at 12:19 AM, Abhinav Roy <ab...@citrix.com>wrote:
> Hi Indra,
>
> Can you check in your KVM host whether the ssvm and cpvm are created or
> not?
> try " virsh list " and see if the vms are there? Is it a Rhel host or
> Ubuntu host??
> Also, check what is the entry in /etc/cloudstack/agent/agent.properties
> file for the "resource" parameter.
>
> Thanks and regards,
> Abhinav
>
> -----Original Message-----
> From: Indra Pramana [mailto:indra@sg.or.id]
> Sent: Wednesday, September 25, 2013 9:32 PM
> To: users@cloudstack.apache.org
> Cc: dev@cloudstack.apache.org
> Subject: Re: Upgrade failed because system VM was created using old
> template?
>
> Hi Abhinav,
>
> We are using KVM.
>
> Thank you.
>
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
Hi Indra,
Can you check in your KVM host whether the ssvm and cpvm are created or not?
try " virsh list " and see if the vms are there? Is it a Rhel host or Ubuntu host??
Also, check what is the entry in /etc/cloudstack/agent/agent.properties file for the "resource" parameter.
Thanks and regards,
Abhinav
-----Original Message-----
From: Indra Pramana [mailto:indra@sg.or.id]
Sent: Wednesday, September 25, 2013 9:32 PM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: Upgrade failed because system VM was created using old template?
Hi Abhinav,
We are using KVM.
Thank you.
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
Hi Indra,
Can you check in your KVM host whether the ssvm and cpvm are created or not?
try " virsh list " and see if the vms are there? Is it a Rhel host or Ubuntu host??
Also, check what is the entry in /etc/cloudstack/agent/agent.properties file for the "resource" parameter.
Thanks and regards,
Abhinav
-----Original Message-----
From: Indra Pramana [mailto:indra@sg.or.id]
Sent: Wednesday, September 25, 2013 9:32 PM
To: users@cloudstack.apache.org
Cc: dev@cloudstack.apache.org
Subject: Re: Upgrade failed because system VM was created using old template?
Hi Abhinav,
We are using KVM.
Thank you.
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Hi Abhinav,
We are using KVM.
Thank you.
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Hi Abhinav,
We are using KVM.
Thank you.
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
Hi Indra,
Which hypervisor are you using?
Thanks and regards,
Abhinav
-----Original Message-----
From: Indra Pramana [mailto:indra@sg.or.id]
Sent: Wednesday, September 25, 2013 9:18 PM
To: dev@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 <ab...@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: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.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.
>
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
Hi Indra,
Which hypervisor are you using?
Thanks and regards,
Abhinav
-----Original Message-----
From: Indra Pramana [mailto:indra@sg.or.id]
Sent: Wednesday, September 25, 2013 9:18 PM
To: dev@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 <ab...@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: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.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.
>
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
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 <ab...@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: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.
>
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
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 <ab...@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: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.
>
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
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.
Re: Upgrade failed because system VM was created using old template?
Posted by Daan Hoogland <da...@gmail.com>.
afaik not, you can define the new one with the documented name and you're
done.
On Fri, Sep 27, 2013 at 5:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> Dear all,
>
> Would like to confirm on this:
>
> On Wed, Sep 25, 2013 at 7:40 PM, Indra Pramana <in...@sg.or.id> wrote:
>
> > 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.
> >
>
> Prior to the upgrade from 4.1.1 to 4.2.0, we need to register the new
> system VM template for 4.2.0. My question, do we also need to delete the
> old system VM template?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
Re: Upgrade failed because system VM was created using old template?
Posted by Daan Hoogland <da...@gmail.com>.
afaik not, you can define the new one with the documented name and you're
done.
On Fri, Sep 27, 2013 at 5:49 AM, Indra Pramana <in...@sg.or.id> wrote:
> Dear all,
>
> Would like to confirm on this:
>
> On Wed, Sep 25, 2013 at 7:40 PM, Indra Pramana <in...@sg.or.id> wrote:
>
> > 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.
> >
>
> Prior to the upgrade from 4.1.1 to 4.2.0, we need to register the new
> system VM template for 4.2.0. My question, do we also need to delete the
> old system VM template?
>
> Looking forward to your reply, thank you.
>
> Cheers.
>
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Dear all,
Would like to confirm on this:
On Wed, Sep 25, 2013 at 7:40 PM, Indra Pramana <in...@sg.or.id> wrote:
> 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.
>
Prior to the upgrade from 4.1.1 to 4.2.0, we need to register the new
system VM template for 4.2.0. My question, do we also need to delete the
old system VM template?
Looking forward to your reply, thank you.
Cheers.
Re: Upgrade failed because system VM was created using old template?
Posted by Indra Pramana <in...@sg.or.id>.
Dear all,
Would like to confirm on this:
On Wed, Sep 25, 2013 at 7:40 PM, Indra Pramana <in...@sg.or.id> wrote:
> 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.
>
Prior to the upgrade from 4.1.1 to 4.2.0, we need to register the new
system VM template for 4.2.0. My question, do we also need to delete the
old system VM template?
Looking forward to your reply, thank you.
Cheers.
RE: Upgrade failed because system VM was created using old template?
Posted by Abhinav Roy <ab...@citrix.com>.
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.