upgrade from 2.2x to 2.2.14
Perform the following to upgrade from 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.4, 2.2.5, 2.2.6, 2.2.7, 2.2.8, 2.2.9, 2.2.10, 2.2.11, 2.2.12, or 2.2.13 to 2.2.14.
1. Stop all Usage Servers if running. Run this on all Usage Server hosts.
# service cloud-usage stop
2. Stop the Management Servers. Run this on all Management Server hosts.
# service cloud-management stop
3. On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging.
In the following commands, it is assumed that you have set the root password on the database, which is a CloudStack recommended best practice. Substitute your own MySQL root password.
# mysqldump -u root -p<mysql_password> cloud > cloud-backup.dmp
# mysqldump -u root -p<mysql_password> cloud_usage > cloud-usage-backup.dmp
4. The resource count table may have duplicate entries which will cause the upgrade to fail. You need to drop those duplicate entries for the same resource type before starting the upgrade.
Replace the password in the following command with the root password you set during MySQL installation.
# mysql -u root -p<password>
mysql> delete from cloud.resource_count;
You will generate a new resource count table later, in step 11.
5. Download the CloudStack Management Server version 2.2.14 onto each host where it will run from one of the following links. If your operating system is CentOS, use the download file for RHEL.
Open-source community: http://sourceforge.net/projects/cloudstack/files/
Commercial customers: https://www.citrix.com/English/ss/downloads/
You will need a MyCitrix account.
6. Upgrade the CloudStack packages. You should have a file in the form of “CloudStack-2.2.14-N-OSVERSION.tar.gz”. Untar the file and then run the install.sh script inside it. Replace the file and directory names below with those you are using:
# tar xzf CloudStack-2.2.14-N-OSVERSION.tar.gz
# cd CloudStack-2.2.14-N-OSVERSION
You should see a few messages as the installer prepares, followed by a list of choices.
7. Choose “U” to upgrade the packages.
8. If you have made changes to your existing copy of the file components.xml in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to further customize the file to be compatible with 2.2.14:
a. Edit components.xml:
# vi /etc/cloud/management/components.xml
b. Remove the following entry:
<adapter name=”GarbageCollecting” class=”com.cloud.storage.allocator.GarbageCollectingStoragePoolAllocator”/>
9. Repeat steps 5 – 8 on every management server node.
10. Start one Management Server. Do not start the other Management Servers.
# service cloud-management start
11. When the UI becomes accessible (at http://<your.management.server.ip>:8080/client), log in with the user ID “admin” and password “password.” Click Domains, then click the ROOT domain. In Actions, click Update Resource Count. This will generate the table deleted in step 4.
12. If upgrading from 2.2.8 or earlier and using vSphere, perform the following. Otherwise, skip to step 14.
The CloudStack 2.2.9 release added flexibility in naming the vCenter management network. This flexibility introduces two new global configuration parameters that must be configured to match the values in vCenter. In deployments with multiple vCenters, each vCenter must be configured with the same management network label. CloudStack defaults these configuration variables to match the defaults provided by vCenter. If you have changed the vCenter defaults, you will need to configure CloudStack with the correct values. CloudStack will assume a management network label of “Management Network” for all ESXi hosts and “Service Console” for all ESX hosts. If you have configured a different name, change the global configuration parameters “vmware.management.portgroup” for ESXi hosts and “vmware.service.console” for ESX hosts to match your deployment’s specific name.
13. If you modified configuration parameters in step 12, restart the Management Server.
# service cloud-management restart
14. Start the other Management Servers. Perform this on each Management Server host.
# service cloud-management start
Note: the CloudStack Management Server logs may contain warnings like the following. These will stop when the upgrade is completed.
java.io.IOException: SSL: Fail to init SSL! java.io.IOException: Connection closed with -1 on reading size
15. Start all Usage Servers (if they were running on your previous CloudStack version). Perform this on each Usage Server host.
# service cloud-usage start
16. (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.
On each KVM host:
a. Copy the 2.2.14 tgz download to the host, untar it, and cd into the resulting directory.
b. Stop the running agent.
# service cloud-agent stop
c. Update the agent software.
Choose “U” to update the packages. > U
d. Start the agent.
# service cloud-agent start
e. Insert a valid username and password into the host_details table on each KVM node. Substitute your own host ID, username, and password in the commands below and submit them to the MySQL server:
insert into cloud.host_details (host_id, name, value) VALUES (the-id-of-host, “username”, the-actual-host-user-name)
insert into cloud.host_details (host_id, name, value) VALUES (the-id-of-host, “password”, the-actual-host-password)
17. In the CloudStack Administrator UI, check the status of the hosts. All hosts should come to Up state (except for those that you know to be offline). You may need to wait 20 or 30 minutes depending on the number of hosts you have. Do not proceed to the next step until the hosts show in Up state. If the hosts do not come to the Up state, contact support.
18. (VMware only) If you are upgrading from version 2.2.7 or earlier, and using VMware ESX hosts, you need to extend the range of firewall ports that the console proxy works with on those hosts. This is to enable the console proxy to work with VMware-based VMs. The default additional port range is 59000-60000. To extend the port range:
a. In the CloudStack UI, choose Configuration ? Global Settings, and set the following parameters:
vmware.additional.vnc.portrange.size = 1000
vmware.additional.vnc.portrange.start = 59000
b. On each ESX host, log in to the VMware ESX service console and run the following commands:
esxcfg-firewall -o 59000-60000,tcp,in,vncextras
esxcfg-firewall -o 59000-60000,tcp,out,vncextras
19. Stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. A script is provided to implement this. Run the script once on one management server. The script requires the IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the “-a” argument.
# nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -a > sysvm.log 2>&1 &
# tail -f sysvm.log
This might take up to an hour to run, depending on the number of accounts in the system.