You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cloudstack.apache.org by Yichi Lu <yi...@sungard.com> on 2014/03/18 03:19:09 UTC
upgrading from CloudPlatform 4.2.0 to CloudStack 4.3.0
I have a problem that bothers me to no end.
I tried to upgrade from CloudPlatform 4.2.0 to CloudStack 4.3.0. So I first
registered a 64-bit 4.3.0 systemvm template from:
http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2
this step was successful. So now I have TWO active systemvm templates. This
can be verified from vm_template table. If now I upgrade the rpm packages
to cloudstack 4.3.0 from CloudPlatform 4.2.0, and restart
cloudstack-management service, I always get a 32-bit ssvm:
root@s-1-VM:~# uname -a
Linux s-1-VM 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux
I was never able to run a 64-bit ssvm for CloudStack 4.3.0.
Any suggestions/thoughts?
Yichi
Re: upgrading from CloudPlatform 4.2.0 to CloudStack 4.3.0
Posted by sebgoa <ru...@gmail.com>.
top posting sorry:
If anyone is testing upgrade paths to 4.3, please do check the release notes:
http://apache-cloudstack-release-notes.readthedocs.org/en/latest/
And send any patches to correct them (edit on github button on the top right of the page)
thanks,
On Mar 18, 2014, at 6:15 AM, Marcus <sh...@gmail.com> wrote:
> I never did get an answer as to how those upgrade instructions are supposed
> to work. I did however look at the code and we came up with our own
> procedure. It's a bit messy because it involves changing the db, use at
> your own risk.
>
> 1. Make changes to system vm template. save as systemvm-ver<num>.qcow2 and
> upload to a place that the ssvm will be able to reach (e.g.
> http://something.com/template).
> 2. Register new qcow2 template in cloudstack under the name/description
> “SystemVM Template v<num> (KVM)”, with Debian 7 as the type.
> 3. Log into mysql for the cloudstack install, find the template, make note
> of template id:
> mysql
> use cloud;
> select * from vm_template where name="SystemVM Template v2 (KVM)";
> 5. Update the template to be a SYSTEM template:mysql update vm_template set
> type='SYSTEM' where id=<id>;
> ▪ New system vms will now use this template simply because it's the highest
> ID SYSTEM template for KVM. Existing system vms will either need to be
> destroyed/recreated, or updated in the db and rebooted if you have
> systemvm.recreate.enabled=true in global settings. Here's how to update so
> that existing system vms will get the new template when rebooted:mysql
> update vm_instance set vm_template_id='<new template id>' where
> vm_template_id='<old template id>';
> If you are unsure of the latest, you can check for the latest template in
> use via:
>
> mysql
> select * from vm_instance where name like 'r-%' order by id desc limit 1;
>
> Finally, go into cloudstack's global config and change the value of
> router.template.kvm to be the name of your system vm template (e.g.
> “SystemVM Template v2 (KVM)”). This will ensure new routers use the
> template.
>
>
>
> On Mar 17, 2014 8:19 PM, "Yichi Lu" <yi...@sungard.com> wrote:
>
>> I have a problem that bothers me to no end.
>> I tried to upgrade from CloudPlatform 4.2.0 to CloudStack 4.3.0. So I first
>> registered a 64-bit 4.3.0 systemvm template from:
>>
>> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2
>>
>> this step was successful. So now I have TWO active systemvm templates. This
>> can be verified from vm_template table. If now I upgrade the rpm packages
>> to cloudstack 4.3.0 from CloudPlatform 4.2.0, and restart
>> cloudstack-management service, I always get a 32-bit ssvm:
>> root@s-1-VM:~# uname -a
>> Linux s-1-VM 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux
>>
>> I was never able to run a 64-bit ssvm for CloudStack 4.3.0.
>>
>> Any suggestions/thoughts?
>>
>> Yichi
>>
Re: upgrading from CloudPlatform 4.2.0 to CloudStack 4.3.0
Posted by Yichi Lu <yi...@sungard.com>.
Marcus:
Thank you for responding to me. I use XenServer. I noticed the relationship
between the vm_template::id and the directory names under
/mnt/secondary/template/tmpl/. The original installation is CloudPlatform
4.2.0, all templates are under /mnt/secondary/template/tmpl/1/<template
id>. Once I upgraded it to CloudStack 4.3.0, all new registered templates
are under /mnt/secondary/template/tmpl/2/<template id>. For instance:
MariaDB [cloud]> select id,unique_name,name,type,bits,state from
vm_template where name like '%XenServer%';
+-----+--------------------------------------------+---------------------------------------+---------+------+----------+
| id | unique_name | name
| type | bits | state |
+-----+--------------------------------------------+---------------------------------------+---------+------+----------+
| 1 | routing-1 | SystemVM Template
(XenServer) | SYSTEM | 32 | Active |
| 2 | centos53-x86_64 | CentOS 5.3(64-bit) no
GUI (XenServer) | BUILTIN | 64 | Inactive |
| 5 | centos56-x86_64-xen | CentOS 5.6(64-bit) no
GUI (XenServer) | BUILTIN | 64 | Active |
| 205 | 205-2-e114251d-0eba-3b2c-9799-66253a82c365 | systemvm-xenserver-4.3
| USER | 64 | Inactive |
| 206 | 206-2-d9dc3603-f98d-37f0-a9c6-9ce7dae6b6ad | systemvm-xenserver-4.3
| SYSTEM | 64 | Active |
+-----+--------------------------------------------+---------------------------------------+---------+------+----------+
5 rows in set (0.00 sec)
Templates with ID's of 1, 2, 5 are under /mnt/secondary/template/tmpl/1/,
205 and 206 under /mnt/secondary/template/tmpl/2/. So there is a tight
connection, at least for XenServer, between the template id and where the
template is located.
What's interesting is the vm_instance,
MariaDB [cloud]> select
id,name,vm_template_id,guest_os_id,vm_type,hypervisor_type from
vm_instance order by id desc;
+----+--------+----------------+-------------+--------------------+-----------------+
| id | name | vm_template_id | guest_os_id | vm_type |
hypervisor_type |
+----+--------+----------------+-------------+--------------------+-----------------+
| 6 | cs6-2 | 204 | 144 | User |
XenServer |
| 5 | r-5-VM | 206 | 183 | DomainRouter |
XenServer |
| 4 | r-4-VM | 206 | 183 | DomainRouter |
XenServer |
| 3 | cs6-1 | 204 | 144 | User |
XenServer |
| 2 | v-2-VM | 206 | 183 | ConsoleProxy |
XenServer |
| 1 | s-1-VM | 206 | 183 | SecondaryStorageVm |
XenServer |
+----+--------+----------------+-------------+--------------------+-----------------+
6 rows in set (0.00 sec)
It says s-1-VM uses vm_template id 206, which should be a 64-bit system,
but guest os id says it is a 32-bit os:
| 183 | NULL | Debian GNU/Linux 7(32-bit) |
| 184 | NULL | Debian GNU/Linux 7(64-bit) |
Eventually I was able to run ssvm with the new systemvm template, by
destroying the existing console vm and ssvm. Without destroying them, you
just get the old vms again and again.
MariaDB [cloud]> select
id,name,vm_template_id,guest_os_id,vm_type,hypervisor_type from
vm_instance order by id desc;
+----+---------+----------------+-------------+--------------------+-----------------+
| id | name | vm_template_id | guest_os_id | vm_type |
hypervisor_type |
+----+---------+----------------+-------------+--------------------+-----------------+
| 15 | s-15-VM | 206 | 184 | SecondaryStorageVm |
XenServer |
| 14 | v-14-VM | 206 | 184 | ConsoleProxy |
XenServer |
| 13 | s-13-VM | 206 | 184 | SecondaryStorageVm |
XenServer |
| 10 | cs6-5 | 204 | 144 | User |
XenServer |
| 7 | cs6-4 | 204 | 144 | User |
XenServer |
| 6 | cs6-2 | 204 | 144 | User |
XenServer |
| 5 | r-5-VM | 206 | 183 | DomainRouter |
XenServer |
| 4 | r-4-VM | 206 | 183 | DomainRouter |
XenServer |
| 3 | cs6-1 | 204 | 144 | User |
XenServer |
| 2 | v-2-VM | 206 | 183 | ConsoleProxy |
XenServer |
| 1 | s-1-VM | 206 | 183 | SecondaryStorageVm |
XenServer |
+----+---------+----------------+-------------+--------------------+-----------------+
11 rows in set (0.00 sec)
root@s-15-VM:~# uname -a
Linux s-15-VM 3.2.0-4-amd64 #1 SMP Debian 3.2.41-2 x86_64 GNU/Linux
Yichi
On Tue, Mar 18, 2014 at 12:15 AM, Marcus <sh...@gmail.com> wrote:
> I never did get an answer as to how those upgrade instructions are supposed
> to work. I did however look at the code and we came up with our own
> procedure. It's a bit messy because it involves changing the db, use at
> your own risk.
>
> 1. Make changes to system vm template. save as systemvm-ver<num>.qcow2 and
> upload to a place that the ssvm will be able to reach (e.g.
> http://something.com/template).
> 2. Register new qcow2 template in cloudstack under the name/description
> “SystemVM Template v<num> (KVM)”, with Debian 7 as the type.
> 3. Log into mysql for the cloudstack install, find the template, make note
> of template id:
> mysql
> use cloud;
> select * from vm_template where name="SystemVM Template v2 (KVM)";
> 5. Update the template to be a SYSTEM template:mysql update vm_template set
> type='SYSTEM' where id=<id>;
> ▪ New system vms will now use this template simply because it's the highest
> ID SYSTEM template for KVM. Existing system vms will either need to be
> destroyed/recreated, or updated in the db and rebooted if you have
> systemvm.recreate.enabled=true in global settings. Here's how to update so
> that existing system vms will get the new template when rebooted:mysql
> update vm_instance set vm_template_id='<new template id>' where
> vm_template_id='<old template id>';
> If you are unsure of the latest, you can check for the latest template in
> use via:
>
> mysql
> select * from vm_instance where name like 'r-%' order by id desc limit 1;
>
> Finally, go into cloudstack's global config and change the value of
> router.template.kvm to be the name of your system vm template (e.g.
> “SystemVM Template v2 (KVM)”). This will ensure new routers use the
> template.
>
>
>
> On Mar 17, 2014 8:19 PM, "Yichi Lu" <yi...@sungard.com> wrote:
>
> > I have a problem that bothers me to no end.
> > I tried to upgrade from CloudPlatform 4.2.0 to CloudStack 4.3.0. So I
> first
> > registered a 64-bit 4.3.0 systemvm template from:
> >
> >
> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2
> >
> > this step was successful. So now I have TWO active systemvm templates.
> This
> > can be verified from vm_template table. If now I upgrade the rpm packages
> > to cloudstack 4.3.0 from CloudPlatform 4.2.0, and restart
> > cloudstack-management service, I always get a 32-bit ssvm:
> > root@s-1-VM:~# uname -a
> > Linux s-1-VM 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux
> >
> > I was never able to run a 64-bit ssvm for CloudStack 4.3.0.
> >
> > Any suggestions/thoughts?
> >
> > Yichi
> >
>
Re: upgrading from CloudPlatform 4.2.0 to CloudStack 4.3.0
Posted by Marcus <sh...@gmail.com>.
I never did get an answer as to how those upgrade instructions are supposed
to work. I did however look at the code and we came up with our own
procedure. It's a bit messy because it involves changing the db, use at
your own risk.
1. Make changes to system vm template. save as systemvm-ver<num>.qcow2 and
upload to a place that the ssvm will be able to reach (e.g.
http://something.com/template).
2. Register new qcow2 template in cloudstack under the name/description
“SystemVM Template v<num> (KVM)”, with Debian 7 as the type.
3. Log into mysql for the cloudstack install, find the template, make note
of template id:
mysql
use cloud;
select * from vm_template where name="SystemVM Template v2 (KVM)";
5. Update the template to be a SYSTEM template:mysql update vm_template set
type='SYSTEM' where id=<id>;
▪ New system vms will now use this template simply because it's the highest
ID SYSTEM template for KVM. Existing system vms will either need to be
destroyed/recreated, or updated in the db and rebooted if you have
systemvm.recreate.enabled=true in global settings. Here's how to update so
that existing system vms will get the new template when rebooted:mysql
update vm_instance set vm_template_id='<new template id>' where
vm_template_id='<old template id>';
If you are unsure of the latest, you can check for the latest template in
use via:
mysql
select * from vm_instance where name like 'r-%' order by id desc limit 1;
Finally, go into cloudstack's global config and change the value of
router.template.kvm to be the name of your system vm template (e.g.
“SystemVM Template v2 (KVM)”). This will ensure new routers use the
template.
On Mar 17, 2014 8:19 PM, "Yichi Lu" <yi...@sungard.com> wrote:
> I have a problem that bothers me to no end.
> I tried to upgrade from CloudPlatform 4.2.0 to CloudStack 4.3.0. So I first
> registered a 64-bit 4.3.0 systemvm template from:
>
> http://download.cloud.com/templates/4.3/systemvm64template-2014-01-14-master-xen.vhd.bz2
>
> this step was successful. So now I have TWO active systemvm templates. This
> can be verified from vm_template table. If now I upgrade the rpm packages
> to cloudstack 4.3.0 from CloudPlatform 4.2.0, and restart
> cloudstack-management service, I always get a 32-bit ssvm:
> root@s-1-VM:~# uname -a
> Linux s-1-VM 3.2.0-4-686-pae #1 SMP Debian 3.2.41-2 i686 GNU/Linux
>
> I was never able to run a 64-bit ssvm for CloudStack 4.3.0.
>
> Any suggestions/thoughts?
>
> Yichi
>