apache/cloudstack
1
0
Fork 0
mirror of https://github.com/apache/cloudstack.git synced 2025-12-19 12:03:50 +01:00
Code Issues Packages Projects Releases Wiki Activity
cloudstack/docs/tmp/en-US/html/upgrade-instructions.html

702 lines
56 KiB
HTML
Raw Blame History

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Chapter 2. Upgrade Instructions</title><link rel="stylesheet" type="text/css" href="Common_Content/css/default.css" /><link rel="stylesheet" media="print" href="Common_Content/css/print.css" type="text/css" /><meta name="generator" content="publican 2.8" /><meta name="package" content="Apache_CloudStack-Release_Notes-4.0.0-incubating-en-US-1-" /><link rel="home" href="index.html" title="Version 4.0.0-incubating Release Notes" /><link rel="up" href="index.html" title="Version 4.0.0-incubating Release Notes" /><link rel="prev" href="submitting-feedback.html" title="Chapter 1. Submitting Feedback and Getting Help" /><link rel="next" href="version-4.0.html" title="Chapter 3. Version 4.0.0-incubating" /></head><body><p id="title"><a class="left" href="http://cloudstack.org"><img src="Common_Content/images/image_left.png" alt="Product Site" /></a><a class="right" href="http://docs.cloudstack.org"><img src="Common_Content/images/image_right.png" alt="Documentation Site" /></a></p><ul class="docnav"><li class="previous"><a accesskey="p" href="submitting-feedback.html"><strong>Prev</strong></a></li><li class="next"><a accesskey="n" href="version-4.0.html"><strong>Next</strong></a></li></ul><div class="chapter" id="upgrade-instructions"><div class="titlepage"><div><div><h2 class="title">Chapter 2. Upgrade Instructions</h2></div></div></div><div class="toc"><dl><dt><span class="section"><a href="upgrade-instructions.html#upgrade-from-3.0.2-to-4.0">2.1. Upgrade from 3.0.2 to 4.0.0-incubating</a></span></dt><dt><span class="section"><a href="upgrade-instructions.html#upgrade-from-2.2.x-to-4.0">2.2. Upgrade from 2.2.14 to 4.0.0-incubating</a></span></dt></dl></div><div class="section" id="upgrade-from-3.0.2-to-4.0"><div class="titlepage"><div><div><h2 class="title" id="upgrade-from-3.0.2-to-4.0">2.1. Upgrade from 3.0.2 to 4.0.0-incubating</h2></div></div></div><div class="para">
Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note.
</div><div class="orderedlist"><ol><li class="listitem"><div class="para">
Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records.
</div><div class="para">
Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available.
</div></li><li class="listitem"><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers.
</div></div></div><div class="para">
In each zone that includes VMware hosts, you need to add a new system VM template.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
While running the existing 3.0.2 system, log in to the UI as root administrator.
</div></li><li class="listitem"><div class="para">
In the left navigation bar, click Templates.
</div></li><li class="listitem"><div class="para">
In Select view, click Templates.
</div></li><li class="listitem"><div class="para">
Click Register template.
</div><div class="para">
The Register template dialog box is displayed.
</div></li><li class="listitem"><div class="para">
In the Register template dialog box, specify the following values (do not change these):
</div><div class="informaltable"><table border="1"><colgroup><col width="33%" align="left" class="1" /><col width="67%" align="left" class="2" /></colgroup><thead><tr><th align="left">
<div class="para">
Field
</div>
</th><th align="left">
<div class="para">
Value
</div>
</th></tr></thead><tbody><tr><td align="left">
<div class="para">
Name
</div>
</td><td align="left">
<div class="para">
systemvm-vmware-3.0.0
</div>
</td></tr><tr><td align="left">
<div class="para">
Description
</div>
</td><td align="left">
<div class="para">
systemvm-vmware-3.0.0
</div>
</td></tr><tr><td align="left">
<div class="para">
URL
</div>
</td><td align="left">
<div class="para">
http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
</div>
</td></tr><tr><td align="left">
<div class="para">
Zone
</div>
</td><td align="left">
<div class="para">
Choose the zone where this hypervisor is used
</div>
</td></tr><tr><td align="left">
<div class="para">
Hypervisor
</div>
</td><td align="left">
<div class="para">
VMware
</div>
</td></tr><tr><td align="left">
<div class="para">
Format
</div>
</td><td align="left">
<div class="para">
OVA
</div>
</td></tr><tr><td align="left">
<div class="para">
OS Type
</div>
</td><td align="left">
<div class="para">
Debian GNU/Linux 5.0 (32-bit)
</div>
</td></tr><tr><td align="left">
<div class="para">
Extractable
</div>
</td><td align="left">
<div class="para">
no
</div>
</td></tr><tr><td align="left">
<div class="para">
Password Enabled
</div>
</td><td align="left">
<div class="para">
no
</div>
</td></tr><tr><td align="left">
<div class="para">
Public
</div>
</td><td align="left">
<div class="para">
no
</div>
</td></tr><tr><td align="left">
<div class="para">
Featured
</div>
</td><td align="left">
<div class="para">
no
</div>
</td></tr></tbody></table></div></li><li class="listitem"><div class="para">
Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful.
</div></li></ol></div></li><li class="listitem"><div class="para">
Stop all Usage Servers if running. Run this on all Usage Server hosts.
</div><pre class="programlisting"># service cloud-usage stop</pre></li><li class="listitem"><div class="para">
Stop the Management Servers. Run this on all Management Server hosts.
</div><pre class="programlisting"># service cloud-management stop</pre></li><li class="listitem"><div class="para">
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.
</div><div class="para">
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.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">mysqldump</code> -u root -p<em class="replaceable"><code>mysql_password</code></em> cloud &gt; <code class="filename">cloud-backup.dmp</code>
<code class="prompt">#</code> <code class="command">mysqldump</code> -u root -p<em class="replaceable"><code>mysql_password</code></em> cloud_usage &gt; <code class="filename">cloud-usage-backup.dmp</code></pre></li><li class="listitem"><div class="para">
Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
</div></li><li class="listitem"><div class="para">
After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
<pre class="programlisting"><code class="prompt">#</code> <code class="command">yum</code> update cloud-*</pre>
<pre class="programlisting"><code class="prompt">#</code> <code class="command">apt-get</code> update
<code class="prompt">#</code> <code class="command">apt-get</code> upgrade cloud-*</pre>
</div><div class="para">
You will, of course, have to agree to the changes suggested by Yum or APT.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files:
</div><pre class="programlisting">warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew</pre><div class="para">
Instructions follow in the next step.
</div></div></div></li><li class="listitem"><div class="para">
If you have made changes to your copy of <code class="filename">/etc/cloud/management/components.xml</code> the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Make a backup copy of <code class="filename">/etc/cloud/management/components.xml</code>. For example:
</div><pre class="programlisting"># mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup</pre></li><li class="listitem"><div class="para">
Copy <code class="filename">/etc/cloud/management/components.xml.rpmnew</code> to create a new <code class="filename">/etc/cloud/management/components.xml</code>:
</div><pre class="programlisting"># cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml</pre></li><li class="listitem"><div class="para">
Merge your changes from the backup file into the new <code class="filename">components.xml</code>.
</div><pre class="programlisting"># vi /etc/cloud/management/components.xml</pre></li></ol></div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
If you have more than one management server node, repeat the upgrade steps on each node.
</div></div></div></li><li class="listitem"><div class="para">
Start the first Management Server. Do not start any other Management Server nodes yet.
</div><pre class="programlisting"># service cloud-management start</pre><div class="para">
Wait until the databases are upgraded. Ensure that the database upgrade is complete. After confirmation, start the other Management Servers one at a time by running the same command on each node.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
Failing to restart the Management Server indicates a problem in the upgrade. Having the Management Server restarted without any issues indicates that the upgrade is successfully completed.
</div></div></div></li><li class="listitem"><div class="para">
Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
</div><div class="para">
<code class="command"># service cloud-usage start</code>
</div></li><li class="listitem"><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
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.
</div></div></div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Configure a yum or apt respository containing the CloudStack packages as outlined in the Installation Guide.
</div></li><li class="listitem"><div class="para">
Stop the running agent.
</div><div class="para">
<code class="command"># service cloud-agent stop</code>
</div></li><li class="listitem"><div class="para">
Update the agent software with one of the following command sets as appropriate for your environment.
</div><div class="para">
<code class="command"># yum update cloud-*</code>
</div><div class="para">
<code class="command"># apt-get update</code>
</div><div class="para">
<code class="command"># apt-get upgrade cloud-*</code>
</div></li><li class="listitem"><div class="para">
Start the agent.
</div><pre class="programlisting"># service cloud-agent start</pre></li><li class="listitem"><div class="para">
Edit <code class="filename">/etc/cloud/agent/agent.properties</code> to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource".
</div></li><li class="listitem"><div class="para">
Start the cloud agent and cloud management services.
</div></li><li class="listitem"><div class="para">
When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
</div></li></ol></div></li><li class="listitem"><div class="para">
Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
Troubleshooting: If login fails, clear your browser cache and reload the page.
</div></div></div><div class="para">
</div><div class="para">
Do not proceed to the next step until the hosts show in Up state.
</div></li><li class="listitem"><div class="para">
If you are upgrading from 3.0.2, perform the following:
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.
</div><div class="para">
This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide.
</div></li><li class="listitem"><div class="para">
Restart the Management Server.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
If you don't want the admin port to remain open, you can set it to null after the upgrade is done and restart the management server.
</div></div></div></li></ol></div></li><li class="listitem"><div class="para">
Run the <code class="command">cloud-sysvmadm</code> script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own 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 <code class="command">-c</code> and <code class="command">-r</code> arguments. For example:
</div><div class="para">
<code class="command"># nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r &gt; sysvm.log 2&gt;&amp;1 &amp;</code>
</div><div class="para">
<code class="command"># tail -f sysvm.log</code>
</div><div class="para">
This might take up to an hour or more to run, depending on the number of accounts in the system.
</div></li><li class="listitem"><div class="para">
If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
</div></li><li class="listitem"><div class="para">
Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Disconnect the XenServer cluster from CloudStack.
</div><div class="para">
In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
</div><div class="para">
This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
</div><div class="para">
Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
</div></li><li class="listitem"><div class="para">
To clean up the VLAN, log in to one XenServer host and run:
</div><div class="para">
<code class="command">/opt/xensource/bin/cloud-clean-vlan.sh</code>
</div></li><li class="listitem"><div class="para">
Now prepare the upgrade by running the following on one XenServer host:
</div><div class="para">
<code class="command">/opt/xensource/bin/cloud-prepare-upgrade.sh</code>
</div><div class="para">
If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again.
</div></li><li class="listitem"><div class="para">
Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp.
</div><div class="para">
On the Xen pool master, upload the hotfix with this command:
</div><div class="para">
<code class="command">xe patch-upload file-name=XS602E003.xsupdate</code>
</div><div class="para">
Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
(Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
</div></div></div></li><li class="listitem"><div class="para">
Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
</div><div class="para">
<code class="command"># xe vm-list</code>
</div><div class="para">
Then use this command to migrate each VM. Replace the example host name and VM name with your own:
</div><div class="para">
<code class="command"># xe vm-migrate live=true host=<em class="replaceable"><code>host-name</code></em> vm=<em class="replaceable"><code>VM-name</code></em></code>
</div><div class="note"><div class="admonition_header"><h2>Troubleshooting</h2></div><div class="admonition"><div class="para">
If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
</div><div class="para">
<code class="command">/opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14</code>.
</div></div></div></li><li class="listitem"><div class="para">
Apply the hotfix. First, get the UUID of this host:
</div><pre class="programlisting"># xe host-list</pre><div class="para">
Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
</div><pre class="programlisting"><code class="command">xe</code> patch-apply host-uuid=<em class="replaceable"><code>host-uuid</code></em> uuid=<em class="replaceable"><code>hotfix-uuid</code></em></pre></li><li class="listitem"><div class="para">
Copy the following files from the CloudStack Management Server to the host.
</div><div class="informaltable"><table border="1"><colgroup><col width="33%" align="left" class="1" /><col width="67%" align="left" class="2" /></colgroup><thead><tr><th align="left">
<div class="para">
Copy from here...
</div>
</th><th align="left">
<div class="para">
...to here
</div>
</th></tr></thead><tbody><tr><td align="left">
<div class="para">
/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py
</div>
</td><td align="left">
<div class="para">
/opt/xensource/sm/NFSSR.py
</div>
</td></tr><tr><td align="left">
<div class="para">
/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh
</div>
</td><td align="left">
<div class="para">
/opt/xensource/bin/setupxenserver.sh
</div>
</td></tr><tr><td align="left">
<div class="para">
/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh
</div>
</td><td align="left">
<div class="para">
/opt/xensource/bin/make_migratable.sh
</div>
</td></tr></tbody></table></div></li><li class="listitem"><div class="para">
(Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
</div><div class="itemizedlist"><ul><li class="listitem"><div class="para">
Download the CSP software onto the XenServer host from one of the following links:
</div><div class="para">
For hotfix XS602E005: <a href="http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz">http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz</a>
</div><div class="para">
For hotfix XS602E007: <a href="http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz">http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz</a>
</div></li><li class="listitem"><div class="para">
Extract the file:
</div><pre class="programlisting"># tar xf xenserver-cloud-supp.tgz</pre></li><li class="listitem"><div class="para">
Run the following script:
</div><pre class="programlisting"># xe-install-supplemental-pack xenserver-cloud-supp.iso</pre></li><li class="listitem"><div class="para">
If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
</div><pre class="programlisting"># xe-switch-network-backend bridge</pre></li></ul></div></li><li class="listitem"><div class="para">
Reboot this XenServer host.
</div></li><li class="listitem"><div class="para">
Run the following:
</div><pre class="programlisting">/opt/xensource/bin/setupxenserver.sh</pre><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
</div></div></div></li><li class="listitem"><div class="para">
Run the following:
</div><pre class="programlisting">for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ;</pre></li><li class="listitem"><div class="para">
On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
</div></li></ol></div></li></ol></div><div class="note"><div class="admonition_header"><h2>Troubleshooting Tip</h2></div><div class="admonition"><div class="para">
If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page.
</div></div></div></div><div class="section" id="upgrade-from-2.2.x-to-4.0"><div class="titlepage"><div><div><h2 class="title" id="upgrade-from-2.2.x-to-4.0">2.2. Upgrade from 2.2.14 to 4.0.0-incubating</h2></div></div></div><div class="orderedlist"><ol><li class="listitem"><div class="para">
Ensure that you query your IPaddress usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.
</div><div class="para">
Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available.
</div></li><li class="listitem"><div class="para">
If you are using version 2.2.0 - 2.2.13, first upgrade to 2.2.14 by using the instructions in the 2.2.14 Release Notes.
</div><div class="warning"><div class="admonition_header"><h2>KVM Hosts</h2></div><div class="admonition"><div class="para">
If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating.
</div></div></div></li><li class="listitem"><div class="para">
While running the 2.2.14 system, log in to the UI as root administrator.
</div></li><li class="listitem"><div class="para">
Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone
</div><div class="orderedlist"><ol><li class="listitem"><div class="para">
In the left navigation bar, click Templates.
</div></li><li class="listitem"><div class="para">
In Select view, click Templates.
</div></li><li class="listitem"><div class="para">
Click Register template.
</div><div class="para">
The Register template dialog box is displayed.
</div></li><li class="listitem"><div class="para">
In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):
</div><div class="informaltable"><table border="1"><colgroup><col width="33%" align="left" class="1" /><col width="67%" align="left" class="2" /></colgroup><thead><tr><th align="left">
<div class="para">
Hypervisor
</div>
</th><th align="left">
<div class="para">
Description
</div>
</th></tr></thead><tbody><tr><td align="left">
<div class="para">
XenServer
</div>
</td><td align="left">
<div class="para">
Name: systemvm-xenserver-3.0.0
</div>
<div class="para">
Description: systemvm-xenserver-3.0.0
</div>
<div class="para">
URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2
</div>
<div class="para">
Zone: Choose the zone where this hypervisor is used
</div>
<div class="para">
Hypervisor: XenServer
</div>
<div class="para">
Format: VHD
</div>
<div class="para">
OS Type: Debian GNU/Linux 5.0 (32-bit)
</div>
<div class="para">
Extractable: no
</div>
<div class="para">
Password Enabled: no
</div>
<div class="para">
Public: no
</div>
<div class="para">
Featured: no
</div>
</td></tr><tr><td align="left">
<div class="para">
KVM
</div>
</td><td align="left">
<div class="para">
Name: systemvm-kvm-3.0.0
</div>
<div class="para">
Description: systemvm-kvm-3.0.0
</div>
<div class="para">
URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2
</div>
<div class="para">
Zone: Choose the zone where this hypervisor is used
</div>
<div class="para">
Hypervisor: KVM
</div>
<div class="para">
Format: QCOW2
</div>
<div class="para">
OS Type: Debian GNU/Linux 5.0 (32-bit)
</div>
<div class="para">
Extractable: no
</div>
<div class="para">
Password Enabled: no
</div>
<div class="para">
Public: no
</div>
<div class="para">
Featured: no
</div>
</td></tr><tr><td align="left">
<div class="para">
VMware
</div>
</td><td align="left">
<div class="para">
Name: systemvm-vmware-3.0.0
</div>
<div class="para">
Description: systemvm-vmware-3.0.0
</div>
<div class="para">
URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova
</div>
<div class="para">
Zone: Choose the zone where this hypervisor is used
</div>
<div class="para">
Hypervisor: VMware
</div>
<div class="para">
Format: OVA
</div>
<div class="para">
OS Type: Debian GNU/Linux 5.0 (32-bit)
</div>
<div class="para">
Extractable: no
</div>
<div class="para">
Password Enabled: no
</div>
<div class="para">
Public: no
</div>
<div class="para">
Featured: no
</div>
</td></tr></tbody></table></div></li></ol></div></li><li class="listitem"><div class="para">
Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful
</div></li><li class="listitem"><div class="para">
<span class="bold bold"><strong>WARNING</strong></span>: If you use more than one type of hypervisor in your cloud, be sure you have repeated these steps to download the system VM template for each hypervisor type. Otherwise, the upgrade will fail.
</div></li><li class="listitem"><div class="para">
Stop all Usage Servers if running. Run this on all Usage Server hosts.
</div><pre class="programlisting"># service cloud-usage stop</pre></li><li class="listitem"><div class="para">
Stop the Management Servers. Run this on all Management Server hosts.
</div><pre class="programlisting"># service cloud-management stop</pre></li><li class="listitem"><div class="para">
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.
</div><div class="para">
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.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">mysqldump</code> -u root -p<em class="replaceable"><code>mysql_password</code></em> cloud &gt; <code class="filename">cloud-backup.dmp</code>
<code class="prompt">#</code> <code class="command">mysqldump</code> -u root -p<em class="replaceable"><code>mysql_password</code></em> cloud_usage &gt; <code class="filename">cloud-usage-backup.dmp</code></pre></li><li class="listitem"><div class="para">
Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the CloudStack binaries.
</div></li><li class="listitem"><div class="para">
After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade CloudStack:
<pre class="programlisting"><code class="prompt">#</code> <code class="command">yum</code> update cloud-*</pre>
<pre class="programlisting"><code class="prompt">#</code> <code class="command">apt-get</code> update
<code class="prompt">#</code> <code class="command">apt-get</code> upgrade cloud-*</pre>
</div><div class="para">
You will, of course, have to agree to the changes suggested by Yum or APT.
</div></li><li class="listitem"><div class="para">
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 place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:
</div></div></div><pre class="programlisting">warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew</pre><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Make a backup copy of your <code class="filename">/etc/cloud/management/components.xml</code> file. For example:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">mv</code> <code class="filename">/etc/cloud/management/components.xml</code> <code class="filename">/etc/cloud/management/components.xml-backup</code></pre></li><li class="listitem"><div class="para">
Copy <code class="filename">/etc/cloud/management/components.xml.rpmnew</code> to create a new <code class="filename">/etc/cloud/management/components.xml</code>:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">cp</code> -ap <code class="filename">/etc/cloud/management/components.xml.rpmnew</code> <code class="filename">/etc/cloud/management/components.xml</code></pre></li><li class="listitem"><div class="para">
Merge your changes from the backup file into the new components.xml file.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">vi</code> <code class="filename">/etc/cloud/management/components.xml</code>
</pre></li></ol></div></li><li class="listitem"><div class="para">
If you have made changes to your existing copy of the <code class="filename">/etc/cloud/management/db.properties</code> file in your previous-version CloudStack installation, the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating.
</div><div class="orderedlist"><ol><li class="listitem"><div class="para">
Make a backup copy of your file <code class="filename">/etc/cloud/management/db.properties</code>. For example:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">mv</code> <code class="filename">/etc/cloud/management/db.properties</code> <code class="filename">/etc/cloud/management/db.properties-backup</code></pre></li><li class="listitem"><div class="para">
Copy <code class="filename">/etc/cloud/management/db.properties.rpmnew</code> to create a new <code class="filename">/etc/cloud/management/db.properties</code>:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">cp</code> -ap <code class="filename">/etc/cloud/management/db.properties.rpmnew</code> <code class="filename">etc/cloud/management/db.properties</code></pre></li><li class="listitem"><div class="para">
Merge your changes from the backup file into the new db.properties file.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">vi</code> <code class="filename">/etc/cloud/management/db.properties</code></pre></li></ol></div></li><li class="listitem"><div class="para">
On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">cloud-setup-encryption</code> -e <em class="replaceable"><code>encryption_type</code></em> -m <em class="replaceable"><code>management_server_key</code></em> -k <em class="replaceable"><code>database_key</code></em></pre><div class="para">
When used without arguments, as in the following example, the default encryption type and keys will be used:
</div><div class="itemizedlist"><ul><li class="listitem"><div class="para">
(Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.
</div></li><li class="listitem"><div class="para">
(Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value
</div></li><li class="listitem"><div class="para">
(Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudStack database. Default: password. It is highly recommended that you replace this with a more secure value.
</div></li></ul></div></li><li class="listitem"><div class="para">
Repeat steps 10 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.
</div></li><li class="listitem"><div class="para">
Start the first Management Server. Do not start any other Management Server nodes yet.
</div><pre class="programlisting"># service cloud-management start</pre><div class="para">
Wait until the databases are upgraded. Ensure that the database upgrade is complete. You should see a message like "Complete! Done." After confirmation, start the other Management Servers one at a time by running the same command on each node.
</div></li><li class="listitem"><div class="para">
Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.
</div><pre class="programlisting"># service cloud-usage start</pre></li><li class="listitem"><div class="para">
(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.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Configure your CloudStack package repositories as outlined in the Installation Guide
</div></li><li class="listitem"><div class="para">
Stop the running agent.
</div><pre class="programlisting"># service cloud-agent stop</pre></li><li class="listitem"><div class="para">
Update the agent software with one of the following command sets as appropriate.
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">yum</code> update cloud-*</pre><pre class="programlisting">
<code class="prompt">#</code> <code class="command">apt-get</code> update
<code class="prompt">#</code> <code class="command">apt-get</code> upgrade cloud-*
</pre></li><li class="listitem"><div class="para">
Start the agent.
</div><pre class="programlisting"># service cloud-agent start</pre></li><li class="listitem"><div class="para">
Copy the contents of the <code class="filename">agent.properties</code> file to the new <code class="filename">agent.properties</code> file by using the following command
</div><pre class="programlisting"><code class="command">sed</code> -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' <code class="filename">/etc/cloud/agent/agent.properties</code></pre></li><li class="listitem"><div class="para">
Start the cloud agent and cloud management services.
</div></li><li class="listitem"><div class="para">
When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features.
</div></li></ol></div></li><li class="listitem"><div class="para">
Log in to the CloudStack UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.
</div><div class="para">
Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.
</div></li><li class="listitem"><div class="para">
Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Run the command once on one management server. Substitute your own 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 "-c" and "-r" arguments. For example:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">nohup cloud-sysvmadm</code> -d <em class="replaceable"><code>192.168.1.5</code></em> -u cloud -p <em class="replaceable"><code>password</code></em> -c -r &gt; sysvm.log 2&gt;&amp;1 &amp;
<code class="prompt">#</code> <code class="command">tail</code> -f <code class="filename">sysvm.log</code></pre><div class="para">
This might take up to an hour or more to run, depending on the number of accounts in the system.
</div></li><li class="listitem"><div class="para">
After the script terminates, check the log to verify correct execution:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">tail</code> -f <code class="filename">sysvm.log</code></pre><div class="para">
The content should be like the following:
</div><pre class="programlisting">
Stopping and starting 1 secondary storage vm(s)...
Done stopping and starting secondary storage vm(s)
Stopping and starting 1 console proxy vm(s)...
Done stopping and starting console proxy vm(s).
Stopping and starting 4 running routing vm(s)...
Done restarting router(s).
</pre></li></ol></div></li><li class="listitem"><div class="para">
If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.
</div><div class="para">
Use one of the following techniques, depending on the hypervisor.
</div><div class="formalpara"><h5 class="formalpara" id="idm10488952">XenServer or KVM:</h5>
SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.
</div><div class="para">
Run the following commands on the XenServer or KVM host on which the system VM is present:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">ssh</code> -i <em class="replaceable"><code>private-key-path</code></em> <em class="replaceable"><code>link-local-ip</code></em> -p 3922
# cat /etc/cloudstack-release</pre><div class="para">
The output should be like the following:
</div><pre class="programlisting">Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012</pre><div class="formalpara"><h5 class="formalpara" id="idm7482664">ESXi</h5>
SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.
</div><div class="para">
Run the following commands on the Management Server:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">ssh</code> -i <em class="replaceable"><code>private-key-path</code></em> <em class="replaceable"><code>private-ip</code></em> -p 3922
<code class="prompt">#</code> <code class="command">cat</code> <code class="filename">/etc/cloudstack-release</code></pre><div class="para">
The output should be like the following:
</div><pre class="programlisting">Cloudstack Release 4.0.0-incubating Mon Oct 9 15:10:04 PST 2012</pre></li><li class="listitem"><div class="para">
If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide.
</div></li><li class="listitem"><div class="para">
Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts.
</div><div class="orderedlist"><ol class="loweralpha"><li class="listitem"><div class="para">
Disconnect the XenServer cluster from CloudStack.
</div><div class="para">
In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.
</div><div class="para">
This may fail if there are hosts not in one of the states Up, Down, Disconnected, or Alert. You may need to fix that before unmanaging this cluster.
</div><div class="para">
Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.
</div></li><li class="listitem"><div class="para">
To clean up the VLAN, log in to one XenServer host and run:
</div><pre class="programlisting">/opt/xensource/bin/cloud-clean-vlan.sh</pre></li><li class="listitem"><div class="para">
Prepare the upgrade by running the following on one XenServer host:
</div><pre class="programlisting">/opt/xensource/bin/cloud-prepare-upgrade.sh</pre><div class="para">
If you see a message like "can't eject CD", log in to the VM and umount the CD, then run this script again.
</div></li><li class="listitem"><div class="para">
Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /root or /tmp.
</div><div class="para">
On the Xen pool master, upload the hotfix with this command:
</div><pre class="programlisting">xe patch-upload file-name=XS602E003.xsupdate</pre><div class="para">
Make a note of the output from this command, which is a UUID for the hotfix file. You'll need it in another step later.
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
(Optional) If you are applying other hotfixes as well, you can repeat the commands in this section with the appropriate hotfix number. For example, XS602E004.xsupdate.
</div></div></div></li><li class="listitem"><div class="para">
Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:
</div><pre class="programlisting"># xe vm-list</pre><div class="para">
Then use this command to migrate each VM. Replace the example host name and VM name with your own:
</div><pre class="programlisting"><code class="prompt">#</code> <code class="command">xe</code> vm-migrate live=true host=<em class="replaceable"><code>host-name</code></em> vm=<em class="replaceable"><code>VM-name</code></em></pre><div class="note"><div class="admonition_header"><h2>Troubleshooting</h2></div><div class="admonition"><div class="para">
If you see a message like "You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected," run:
</div><div class="para">
<code class="command">/opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14</code>.
</div></div></div></li><li class="listitem"><div class="para">
Apply the hotfix. First, get the UUID of this host:
</div><div class="para">
<code class="command"># xe host-list</code>
</div><div class="para">
Then use the following command to apply the hotfix. Replace the example host UUID with the current host ID, and replace the hotfix UUID with the output from the patch-upload command you ran on this machine earlier. You can also get the hotfix UUID by running xe patch-list.
</div><div class="para">
<code class="command">xe patch-apply host-uuid=<em class="replaceable"><code>host-uuid</code></em> uuid=<em class="replaceable"><code>hotfix-uuid</code></em></code>
</div></li><li class="listitem"><div class="para">
Copy the following files from the CloudStack Management Server to the host.
</div><div class="informaltable"><table border="1"><colgroup><col width="33%" align="left" class="1" /><col width="67%" align="left" class="2" /></colgroup><thead><tr><th align="left">
<div class="para">
Copy from here...
</div>
</th><th align="left">
<div class="para">
...to here
</div>
</th></tr></thead><tbody><tr><td align="left">
<div class="para">
<code class="filename">/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py</code>
</div>
</td><td align="left">
<div class="para">
<code class="filename">/opt/xensource/sm/NFSSR.py</code>
</div>
</td></tr><tr><td align="left">
<div class="para">
<code class="filename">/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh</code>
</div>
</td><td align="left">
<div class="para">
<code class="filename">/opt/xensource/bin/setupxenserver.sh</code>
</div>
</td></tr><tr><td align="left">
<div class="para">
<code class="filename">/usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh</code>
</div>
</td><td align="left">
<div class="para">
<code class="filename">/opt/xensource/bin/make_migratable.sh</code>
</div>
</td></tr></tbody></table></div></li><li class="listitem"><div class="para">
(Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack.
</div><div class="itemizedlist"><ul><li class="listitem"><div class="para">
Download the CSP software onto the XenServer host from one of the following links:
</div><div class="para">
For hotfix XS602E005: <a href="http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz">http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz</a>
</div><div class="para">
For hotfix XS602E007: <a href="http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz">http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz</a>
</div></li><li class="listitem"><div class="para">
Extract the file:
</div><div class="para">
<code class="command"># tar xf xenserver-cloud-supp.tgz</code>
</div></li><li class="listitem"><div class="para">
Run the following script:
</div><div class="para">
<code class="command"># xe-install-supplemental-pack xenserver-cloud-supp.iso</code>
</div></li><li class="listitem"><div class="para">
If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS):
</div><div class="para">
<code class="command"># xe-switch-network-backend bridge</code>
</div></li></ul></div></li><li class="listitem"><div class="para">
Reboot this XenServer host.
</div></li><li class="listitem"><div class="para">
Run the following:
</div><div class="para">
<code class="command">/opt/xensource/bin/setupxenserver.sh</code>
</div><div class="note"><div class="admonition_header"><h2>Note</h2></div><div class="admonition"><div class="para">
If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.
</div></div></div></li><li class="listitem"><div class="para">
Run the following:
</div><div class="para">
<code class="command">for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; </code>
</div></li><li class="listitem"><div class="para">
On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."
</div></li></ol></div></li></ol></div></div></div><ul class="docnav"><li class="previous"><a accesskey="p" href="submitting-feedback.html"><strong>Prev</strong>Chapter 1. Submitting Feedback and Getting Help</a></li><li class="up"><a accesskey="u" href="#"><strong>Up</strong></a></li><li class="home"><a accesskey="h" href="index.html"><strong>Home</strong></a></li><li class="next"><a accesskey="n" href="version-4.0.html"><strong>Next</strong>Chapter 3. Version 4.0.0-incubating</a></li></ul></body></html>
Reference in New Issue View Git Blame Copy Permalink