cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Yichi Lu <yichi...@sungard.com>
Subject Re: upgrading from CloudPlatform 4.2.0 to CloudStack 4.3.0
Date Tue, 18 Mar 2014 21:39:17 GMT
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 <shadowsor@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" <yichi.lu@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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message