Upgrade Instruction from 4.13.x

This section will show you how to upgrade from CloudStack 4.13.x to latest CloudStack 4.13.1.0.

Any steps that are hypervisor-specific will be called out with a note.

We recommend reading through this section once or twice before beginning your upgrade procedure, and working through it on a test system before working on a production system.

Note

The following upgrade instructions should be performed regardless of hypervisor type.

Overview of Upgrade Steps:

  1. Check any customisations and integrations
  2. Stop all running management servers
  3. Backup CloudStack database (MySQL)
  4. Upgrade 1st CloudStack management server
  5. Update hypervisors specific dependencies
  6. Restart 1st management server
  7. Check that your upgraded environment works as expected
  8. Upgrade and restart the remaining management servers

CloudStack Customisations

There are a number of ways in which administrators can customise CloudStack. During an upgrade, a number of these could be overridden. Therefore steps should be taken to ensure that they can be restored after the upgrade is completed.

Guest OS mappings

A new CloudStack release often brings compatibility with new hypervisors, and therefore new Guest OS mappings. An API is provided to manually add guest OSes and the relevant hypervisor mappings, however, there is a high probability that manually added guest OSes and/or mappings would conflict with guest OSes and/or mappings added as part of a version upgrade.

It is therefore essential to remove any Guest OS mappings that were manually added in order to ensure a successful upgrade. If need be, any custom Guest OS mappings still ‘missing’ after an upgrade can be re-added after the upgrade. That means that any custom added rows in the guest_os, guest_os_hypervisor, guest_os_details and guest_os_category database tables, should be removed prior to the upgrade, and added later if needed.

Warning

Manually added guest OS mappings can cause the upgrade process to fail.

Customised CSS

If you have altered the CSS files in order to customise the appearance of the CloudStack UI, you should make a backup copy as the installed CSS files are likely to be overwritten during any upgrade.

You should inspect a ‘diff’ of your customised css files and the new versions, and then reapply your changes to the new files as the new versions may contain changes to better display existing elements or have new entries to support new UI elements.

Plugins

If you have 3rd party plugins installed, you should backup your plugins directories and the plugins.js file. While the plugins directories should remain untouched, the plugins.js file is likely to be overwritten.

3rd Party Integrations

CloudStack is put through extensive regression testing during a release cycle, however the numerous 3rd party integrations which are available cannot all be tested by the community nor indeed may the community know about many of them. Therefore it is essential that you verify that your integrations will continue to work after an upgrade through thorough testing and checking with the vendor/supplier of your integrations.

Warning

CloudStack 4.13.1.0 uses the same systemVM templates as 4.13.x, so there is no need for a new systemVM template.

Packages repository

Most users of CloudStack manage the installation and upgrades of CloudStack with one of Linux’s predominant package systems, RPM or APT. This guide assumes you’ll be using RPM and Yum (for Red Hat Enterprise Linux or CentOS), or APT and Debian packages (for Ubuntu).

Create RPM or Debian packages (as appropriate) and a repository from the 4.13.1.0 source, or check the Apache CloudStack downloads page at http://cloudstack.apache.org/downloads.html for package repositories supplied by community members. You will need them for Management Server or CentOS/RHEL and Hypervisor: KVM hosts upgrade.

Instructions for creating packages from the CloudStack source are in the CloudStack Installation Guide.

Database Preparation

Backup current database

  1. Stop your management server or servers. Run this on all management server hosts:

    1. $ sudo service cloudstack-management stop

  2. If you are running a usage server or usage servers, stop those as well:

    1. $ sudo service cloudstack-usage stop

  3. Make a backup of your MySQL database. If you run into any issues or need to roll back the upgrade, this will assist in debugging or restoring your existing environment. You’ll be prompted for your password.

    1. $ mysqldump -u root -p cloud > cloud-backup_`date '+%Y-%m-%d'.sql
    2. $ mysqldump -u root -p cloud_usage > cloud_usage-backup_`date '+%Y-%m-%d'.sql

  4. (KVM Only) If primary storage of type local storage is in use, the path for this storage needs to be verified to ensure it passes new validation. Check local storage by querying the cloud.storage_pool table:

    1. $ mysql -u cloud -p -e "select id,name,path from cloud.storage_pool where pool_type='Filesystem'"

    If local storage paths are found to have a trailing forward slash, remove it:

    1. $ mysql -u cloud -p -e 'update cloud.storage_pool set path="/var/lib/libvirt/images" where path="/var/lib/libvirt/images/"';

Management Server

Ubuntu

If you are using Ubuntu, follow this procedure to upgrade your packages. If not, skip to step CentOS/RHEL.

Note

Community Packages: This section assumes you’re using the community supplied packages for CloudStack. If you’ve created your own packages and APT repository, substitute your own URL for the ones used in these examples.

The first order of business will be to change the sources list for each system with CloudStack packages. This means all management servers, and any hosts that have the KVM agent (no changes should be necessary for hosts that are running VMware or Xen.)

Make sure that your /etc/apt/sources.list.d/cloudstack.list file on any systems that have CloudStack packages installed points to version 4.13

This file should have one line, which contains:

  1. deb http://download.cloudstack.org/ubuntu precise 4.13

  1. Now update your apt package list:

    1. $ sudo apt-get update

  2. Now that you have the repository configured, it’s time to upgrade the cloudstack-management package.

    1. $ sudo apt-get upgrade cloudstack-management

  3. If you use CloudStack usage server

    1. $ sudo apt-get upgrade cloudstack-usage

CentOS/RHEL

If you are using CentOS or RHEL, follow this procedure to upgrade your packages. If not, skip to hypervisors section Upgrade Hypervisors.

Note

Community Packages: This section assumes you’re using the community supplied packages for CloudStack. If you’ve created your own packages and yum repository, substitute your own URL for the ones used in these examples.

The first order of business will be to change the yum repository for each system with CloudStack packages. This means all management servers, and any hosts that have the KVM agent (no changes should be necessary for hosts that are running VMware or Xen.)

Confirm your /etc/yum.repos.d/cloudstack.repo file on any systems that have CloudStack packages installed points to version 4.13.

This file should have content similar to the following:

  1. [apache-cloudstack]
  2. name=Apache CloudStack
  3. baseurl=http://download.cloudstack.org/centos/7/4.13/
  4. enabled=1
  5. gpgcheck=0

Setup the GPG public key if you wish to enable gpgcheck=1:

  1. rpm --import http://download.cloudstack.org/RPM-GPG-KEY

  1. Now that you have the repository configured, it’s time to upgrade the cloudstack-management.

    1. $ sudo yum upgrade cloudstack-management

  2. If you use CloudStack usage server

    1. $ sudo yum upgrade cloudstack-usage

Upgrade Hypervisors

Hypervisor: XenServer

No additional steps are required for XenServer Hypervisor for this upgrade.

Hypervisor: VMware

Warning

For VMware hypervisor CloudStack management server packages must be build using “noredist”. Refer to Building Non-OSS.

No additional steps are requried for the VMware Hypervisor for this upgrade.

Hypervisor: KVM

KVM on Ubuntu

(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.

  1. Configure the APT repo as detailed above.

  2. Stop the running agent.

    1. $ sudo service cloudstack-agent stop

  3. Update the agent software.

    1. $ sudo apt-get upgrade cloudstack-agent

  4. Start the agent.

    1. $ sudo service cloudstack-agent start

KVM on CentOS/RHEL

For KVM hosts, upgrade the cloudstack-agent package

  1. Configure the rpm-repo413 as detailed above.

    1. $ sudo yum upgrade cloudstack-agent

  2. Restart the agent:

    1. $ sudo service cloudstack-agent stop
    2. $ sudo killall jsvc
    3. $ sudo service cloudstack-agent start

Restart management services

  1. Now it’s time to start the management server

    1. $ sudo service cloudstack-management start

  2. If you use it, start the usage server

    1. $ sudo service cloudstack-usage start