[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-492?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Kirk Kosinski updated CLOUDSTACK-492:
-------------------------------------

    Description: 
While it is possible to manually change the System Offering for a particular 
System VM, a CloudStack administrator may want to change the System Offering 
used by default for System VMs. It would be useful for this procedure to be 
documented. The following procedure works for me on CloudStack 3.0.2 and 
4.0.0-incubating.

1. Create a new system offering with the desired settings. This can be done via 
UI under the Service Offerings tab. 
2. Back up the database. 
mysqldump -u root -p cloud | bzip2 > cloud_backup.sql.bz2 
3. Open a mysql prompt to be able to run queries in later steps on the cloud 
database.
mysql -u cloud -p cloud
4. In the disk_offering table in the database, identify the original default 
offering and the new offering you wish to be used by default. Make a note of 
their id. 
select id,name,unique_name,type from disk_offering; 
5. Set unique_name = NULL for the original default offering. It is important to 
use the correct value for id. 
update disk_offering set unique_name = NULL where id = 10; 
6. For the new offering you wish to be used by default, set unique_name = 
'Cloud.com-ConsoleProxy' (for the default CPVM offering) or 
'Cloud.com-SecondaryStorage' (for the default SSVM offering). 
update disk_offering set unique_name = 'Cloud.com-ConsoleProxy' where id = 16; 
7. Restart CloudStack. This is required because the default offerings are 
loaded into memory at start-up. 
service cloud-management restart 
8. Destroy the existing CPVM or SSVM and wait for it to be recreated. The new 
CPVM or SSVM will be configured with the new offering. 

Note that CLOUDSTACK-338 seems to be requesting that the string used in 
unique_name be change. When that happens, this procedure would need to be 
updated with the correct string.


  was:
While it is possible to manully change the System Offering for a particular 
System VM, a CloudStack administrator may want to change the System Offering 
used by default for System VMs. It would be useful for this procedure to be 
documented. The following procedure works for me on CloudStack 3.0.2 and 
4.0.0-incubating.

1. Create a new system offering with the desired settings. This can be done via 
UI under the Service Offerings tab. 
2. Back up the database. 
mysqldump -u root -p cloud | bzip2 > cloud_backup.sql.bz2 
3. Open a mysql prompt to be able to run queries in later steps on the cloud 
database.
mysql -u cloud -p cloud
4. In the disk_offering table in the database, identify the original default 
offering and the new offering you wish to be used by default. Make a note of 
their id. 
select id,name,unique_name,type from disk_offering; 
5. Set unique_name = NULL for the original default offering. It is important to 
use the correct value for id. 
update disk_offering set unique_name = NULL where id = 10; 
6. For the new offering you wish to be used by default, set unique_name = 
'Cloud.com-ConsoleProxy' (for the default CPVM offering) or 
'Cloud.com-SecondaryStorage' (for the default SSVM offering). 
update disk_offering set unique_name = 'Cloud.com-ConsoleProxy' where id = 16; 
7. Restart CloudStack. This is required because the default offerings are 
loaded into memory at start-up. 
service cloud-management restart 
8. Destroy the existing CPVM or SSVM and wait for it to be recreated. The new 
CPVM or SSVM will be configured with the new offering. 

Note that CLOUDSTACK-338 seems to be requesting that the string used in 
unique_name be change. When that happens, this procedure would need to be 
updated with the correct string.


    
> Document procedure to choose default System Offering for System VMs
> -------------------------------------------------------------------
>
>                 Key: CLOUDSTACK-492
>                 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-492
>             Project: CloudStack
>          Issue Type: New Feature
>          Components: Doc
>    Affects Versions: 4.0.0
>            Reporter: Kirk Kosinski
>            Priority: Minor
>              Labels: adminguide
>
> While it is possible to manually change the System Offering for a particular 
> System VM, a CloudStack administrator may want to change the System Offering 
> used by default for System VMs. It would be useful for this procedure to be 
> documented. The following procedure works for me on CloudStack 3.0.2 and 
> 4.0.0-incubating.
> 1. Create a new system offering with the desired settings. This can be done 
> via UI under the Service Offerings tab. 
> 2. Back up the database. 
> mysqldump -u root -p cloud | bzip2 > cloud_backup.sql.bz2 
> 3. Open a mysql prompt to be able to run queries in later steps on the cloud 
> database.
> mysql -u cloud -p cloud
> 4. In the disk_offering table in the database, identify the original default 
> offering and the new offering you wish to be used by default. Make a note of 
> their id. 
> select id,name,unique_name,type from disk_offering; 
> 5. Set unique_name = NULL for the original default offering. It is important 
> to use the correct value for id. 
> update disk_offering set unique_name = NULL where id = 10; 
> 6. For the new offering you wish to be used by default, set unique_name = 
> 'Cloud.com-ConsoleProxy' (for the default CPVM offering) or 
> 'Cloud.com-SecondaryStorage' (for the default SSVM offering). 
> update disk_offering set unique_name = 'Cloud.com-ConsoleProxy' where id = 
> 16; 
> 7. Restart CloudStack. This is required because the default offerings are 
> loaded into memory at start-up. 
> service cloud-management restart 
> 8. Destroy the existing CPVM or SSVM and wait for it to be recreated. The new 
> CPVM or SSVM will be configured with the new offering. 
> Note that CLOUDSTACK-338 seems to be requesting that the string used in 
> unique_name be change. When that happens, this procedure would need to be 
> updated with the correct string.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

Reply via email to