You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cloudstack.apache.org by wi...@apache.org on 2012/08/16 23:39:36 UTC
[2/3] docs: Some minor cleanup of files that had tabs instead of
spaces.
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/c383d38c/docs/en-US/release-notes-3.0.4.xml
----------------------------------------------------------------------
diff --git a/docs/en-US/release-notes-3.0.4.xml b/docs/en-US/release-notes-3.0.4.xml
deleted file mode 100644
index 744d3d2..0000000
--- a/docs/en-US/release-notes-3.0.4.xml
+++ /dev/null
@@ -1,2435 +0,0 @@
-<?xml version='1.0' encoding='utf-8' ?>
-<!DOCTYPE book PUBLIC "-//OASIS//DTD DocBook XML V4.5//EN" "http://www.oasis-open.org/docbook/xml/4.5/docbookx.dtd" [
-<!ENTITY % BOOK_ENTITIES SYSTEM "cloudstack.ent">
-%BOOK_ENTITIES;
-]>
-
-<!-- Licensed to the Apache Software Foundation (ASF) under one
- or more contributor license agreements. See the NOTICE file
- distributed with this work for additional information
- regarding copyright ownership. The ASF licenses this file
- to you under the Apache License, Version 2.0 (the
- "License"); you may not use this file except in compliance
- with the License. You may obtain a copy of the License at
-
- http://www.apache.org/licenses/LICENSE-2.0
-
- Unless required by applicable law or agreed to in writing,
- software distributed under the License is distributed on an
- "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
- KIND, either express or implied. See the License for the
- specific language governing permissions and limitations
- under the License.
--->
-
-<book>
- <xi:include href="Book_Info.xml" xmlns:xi="http://www.w3.org/2001/XInclude" />
- <chapter id="submitting-feedback">
- <title>Submitting Feedback and Getting Help</title>
- <para>The support team is available to help customers plan and execute their installations. To contact the support team, log in to <ulink url="http://support.citrix.com/cms/kc/cloud-home/"> the Support Portal</ulink> by using the account credentials you received when you purchased your support contract.</para>
- </chapter>
- <chapter id="upgrade-instructions">
- <title>Upgrade Instructions</title>
- <section id="upgrade-from-3.0.x-to-3.0.4">
- <title>Upgrade from 3.0.x to 3.0.4</title>
- <para>Perform the following to upgrade from version 3.0.0, 3.0.1, 3.0.2, or 3.0.3 to version 3.0.4.</para>
- <orderedlist>
- <listitem><para>If you are upgrading from 3.0.0 or 3.0.1, ensure that you query your IP address usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.</para>
- <para>Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. See <ulink url="http://bugs.cloudstack.org/browse/CS-8222">bug CS-8222</ulink>). 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.</para></listitem>
- <listitem><para>Stop all Usage Servers if running. Run this on all Usage Server hosts.</para><programlisting># service cloud-usage stop</programlisting></listitem>
- <listitem><para>Stop the Management Servers. Run this on all Management Server hosts.</para><programlisting># service cloud-management stop</programlisting></listitem>
- <listitem><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.</para>
- <para>In the following commands, it is assumed that you have set the root password on the database, which is a &PRODUCT; recommended best practice. Substitute your own MySQL root password.</para>
- <programlisting># mysqldump -u root -p<mysql_password> cloud >> cloud-backup.dmp
-# mysqldump -u root -p<mysql_password> cloud_usage > cloud-usage-backup.dmp
-</programlisting></listitem>
- <listitem><para>Download &PRODUCT; 3.0.4 onto management server host where it will run. Get the software from the following link:</para>
- <para><ulink url="https://www.citrix.com/English/ss/downloads/"></ulink>.</para>
- <para> You need a <ulink url="http://www.citrix.com/lang/English/publicindex.asp?destURL=%2FEnglish%2FmyCitrix%2Findex.asp%3F#">My Citrix Account</ulink>.</para></listitem>
- <listitem><para>Upgrade the &PRODUCT; packages. You should have a file in the form of
- “CloudStack-3.0.4-N-OSVERSION.tar.gz”. Untar the file, then run the install.sh script inside it. Replace the file and directory names below with those you are using:
- </para><programlisting># tar xzf CloudStack-3.0.4-N-OSVERSION.tar.gz
-# cd CloudStack-3.0.4-N-OSVERSION
-# ./install.sh
-</programlisting>
- <para>You should see a few messages as the installer prepares, followed by a list of choices.</para></listitem>
- <listitem><para>Choose "U" to upgrade the package</para><programlisting>>U</programlisting><para>You should see some output as the upgrade proceeds, ending with a message like "Complete! Done."</para></listitem>
- <listitem><para>If you have made changes to your existing copy of the file components.xml in your previous-version &PRODUCT; 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 3.0.4.</para>
- <note><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:</para></note>
- <programlisting>warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew </programlisting>
- <orderedlist numeration="loweralpha">
- <listitem><para>Make a backup copy of your /etc/cloud/management/components.xml file. For example:</para>
- <programlisting># mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup</programlisting></listitem>
- <listitem><para>Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:</para>
- <programlisting># cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml</programlisting></listitem>
- <listitem><para>Merge your changes from the backup file into the new components.xml file.</para><programlisting># vi /etc/cloud/management/components.xml</programlisting></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>Repeat steps 5 - 8 on each management server node.</para></listitem>
- <listitem><para>Start the first Management Server. Do not start any other Management Server nodes yet.</para>
- <programlisting># service cloud-management start</programlisting><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.</para>
- <note><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.</para></note></listitem>
- <listitem><para>Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.</para>
- <programlisting># service cloud-usage start</programlisting></listitem>
- <listitem><para>12. (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.</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Copy the &PRODUCT; 3.0.4 tar file to the host, untar it, and change directory to the resulting directory.</para></listitem>
- <listitem><para>Stop the running agent.</para>
- <programlisting># service cloud-agent stop</programlisting></listitem>
- <listitem><para>Update the agent software.</para><programlisting># ./install.sh</programlisting></listitem>
- <listitem><para>Choose "U" to update the packages.</para></listitem>
- <listitem><para>Start the agent.</para><programlisting># service cloud-agent start</programlisting></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>Log in to the &PRODUCT; 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.</para>
- <note><para>Troubleshooting: If login fails, clear your browser cache and reload the page.</para></note>
- <para>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.</para></listitem>
- <listitem><para>If you are upgrading from 3.0.1 or 3.0.2, perform the following:</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.</para>
- <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 “Edit the Global Configuration Settings” in the Advanced Installation Guide.</para></listitem>
- <listitem><para>Restart the Management Server.</para>
- <note><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</para></note></listitem>
- </orderedlist></listitem>
- <listitem><para>Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. 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. For example:</para>
- <programlisting># nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -a > sysvm.log 2>&1 &
-# tail -f sysvm.log
-</programlisting>
- <para>This might take up to an hour or more to run, depending on the number of accounts in the system.</para></listitem>
- <listitem>
- <para>In order to deploy AWS API on its new port (7080), you need to deploy it under a separate webapps folder and make some changes to port settings.</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Create the new webapps folder:</para>
- <programlisting># mkdir -p /usr/share/cloud/management/webapps7080</programlisting>
- </listitem>
- <listitem><para>Create a symbolic link:</para>
- <programlisting># ln -s /usr/share/cloud/bridge/webapps/awsapi /usr/share/cloud/management/webapps7080/awsapi</programlisting>
- </listitem>
- <listitem><para>Remove the old folder:</para>
- <programlisting># rm /usr/share/cloud/management/webapps/awsapi</programlisting>
- </listitem>
- <listitem><para>Open port 7080:</para>
- <programlisting># iptables -I INPUT -p tcp -m tcp --dport 7080 -j ACCEPT</programlisting>
- </listitem>
- <listitem><para>If you have made any modifications in server.xml on your existing &PRODUCT; installation, back it up:</para>
- <programlisting># mv /etc/cloud/management/server.xml /etc/cloud/management/server.xml-backup</programlisting>
- <para>Then replace with the new server.xml file:</para>
- <programlisting># cp /etc/cloud/management/server.xml.rpmnew /etc/cloud/management/server.xml</programlisting>
- <para>Merge any changes from the backup file into the new server.xml file.</para>
- <programlisting># vi /etc/cloud/management/server.xml</programlisting>
- </listitem>
- <listitem><para>Open the /etc/cloud/management/ec2.service.properties file in your favorite editor. For example:</para>
- <programlisting># vi /etc/cloud/management/ec2.service.properties</programlisting>
- <para>Add the following to specify the Management Server host and port to which AWS API calls should be forwarded. Substitute your actual Management Server IP address.</para>
- <programlisting>
-managementServer=<management.server.IP.address>
-cloudAPIPort=8080
- </programlisting>
- </listitem>
- <listitem><para>Restart the Management Server to put the new settings into effect.</para></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by &PRODUCT; 3.0.4. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the &PRODUCT; 3.0.3 Advanced Installation Guide.</para></listitem>
- <listitem><para>Now apply the XenServer hotfix XS602E003 to XenServer v6.0.2 hypervisor hosts. (Support for this hotfix is the reason for release 3.0.4.)</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Disconnect the XenServer cluster from &PRODUCT;.</para>
- <para>In the left navigation bar of the &PRODUCT; UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.</para>
- <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.</para>
- <para>Wait until the status of the cluster has reached Unmanaged. Use the &PRODUCT; UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.</para>
- </listitem>
- <listitem><para>To clean up the VLAN, log in to one XenServer host and run:</para>
- <programlisting>/opt/xensource/bin/cloud-clean-vlan.sh</programlisting>
- </listitem>
- <listitem>
- <para>Now prepare the upgrade by running the following on one XenServer host:</para>
- <programlisting>/opt/xensource/bin/cloud-prepare-upgrade.sh</programlisting>
- <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.</para>
- </listitem>
- <listitem><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. </para>
- <para>On the Xen pool master, upload the hotfix with this command:</para>
- <programlisting>xe patch-upload file-name=XS602E003.xsupdate</programlisting>
- <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.</para>
- <note><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.</para></note>
- </listitem>
- <listitem><para>Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:</para>
- <programlisting># xe vm-list</programlisting>
- <para>Then use this command to migrate each VM. Replace the example host name and VM name with your own:</para>
- <programlisting># xe vm-migrate live=true host=<host-name> vm=<VM-name></programlisting>
- <para><emphasis role="bold">Troubleshooting:</emphasis> 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 /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.</para>
- </listitem>
- <listitem><para>Apply the hotfix. First, get the UUID of this host:</para>
- <programlisting># xe host-list</programlisting>
- <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.
- </para>
- <programlisting>xe patch-apply host-uuid=<host-uuid> uuid=<hotfix-uuid></programlisting>
- </listitem>
- <listitem><para>Copy the following files from the &PRODUCT; Management Server to the host.</para>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Copy from here...</para></entry>
- <entry><para>...to here</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py</para></entry>
- <entry><para>/opt/xensource/sm/NFSSR.py</para></entry>
- </row>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/setupxenserver.sh</para></entry>
- <entry><para>/opt/xensource/bin/setupxenserver.sh</para></entry>
- </row>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/make_migratable.sh</para></entry>
- <entry><para>/opt/xensource/bin/make_migratable.sh</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </listitem>
- <listitem><para>Reboot this XenServer host.</para></listitem>
- <listitem><para>Run the following:</para>
- <programlisting>/opt/xensource/bin/setupxenserver.sh</programlisting>
- <note><para>If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.</para></note>
- </listitem>
- <listitem><para>Run the following:</para>
- <programlisting>for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; </programlisting>
- </listitem>
- <listitem><para>On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."</para></listitem>
- </orderedlist>
- </listitem>
- </orderedlist>
-
- </section>
- <section id="upgrade-from--2.2.x-to-3.0.4">
- <title>Upgrade from 2.2.x to 3.0.4</title>
- <orderedlist>
- <listitem><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.</para>
- <para>Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. See <ulink url="http://bugs.cloudstack.org/browse/CS-8222">CS-8222</ulink>. 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 3.0.4, any existing IP address usage records in the old format will no longer be available.</para></listitem>
- <listitem><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.</para>
- <note><para>(KVM only) 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 3.0.4.</para></note></listitem>
- <listitem><para>While running the 2.2.14 system, log in to the UI as root administrator.</para></listitem>
- <listitem><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</para>
- <orderedlist>
- <listitem><para>In the left navigation bar, click Templates.</para></listitem>
- <listitem><para>In Select view, click Templates.</para></listitem>
- <listitem><para>Click Register template.</para><para>The Register template dialog box is displayed.</para></listitem>
- <listitem><para>In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):</para>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Hypervisor</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>XenServer</para></entry>
- <entry><para>Name: systemvm-xenserver-3.0.0</para>
- <para>Description: systemvm-xenserver-3.0.0</para>
- <para>URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2</para>
- <para>Zone: Choose the zone where this hypervisor is used</para>
- <para>Hypervisor: XenServer</para>
- <para>Format: VHD</para>
- <para>OS Type: Debian GNU/Linux 5.0 (32-bit)</para>
- <para>Extractable: no</para>
- <para>Password Enabled: no</para>
- <para>Public: no</para>
- <para>Featured: no</para>
- </entry>
- </row>
- <row>
- <entry><para>KVM</para></entry>
- <entry><para>Name: systemvm-kvm-3.0.0</para>
- <para>Description: systemvm-kvm-3.0.0</para>
- <para>URL: http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2</para>
- <para>Zone: Choose the zone where this hypervisor is used</para>
- <para>Hypervisor: KVM</para>
- <para>Format: QCOW2</para>
- <para>OS Type: Debian GNU/Linux 5.0 (32-bit)</para>
- <para>Extractable: no</para>
- <para>Password Enabled: no</para>
- <para>Public: no</para>
- <para>Featured: no</para>
- </entry>
- </row>
- <row>
- <entry><para>VMware</para></entry>
- <entry><para>Name: systemvm-vmware-3.0.0</para>
- <para>Description: systemvm-vmware-3.0.0</para>
- <para>URL: http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova</para>
- <para>Zone: Choose the zone where this hypervisor is used</para>
- <para>Hypervisor: VMware</para>
- <para>Format: OVA</para>
- <para>OS Type: Debian GNU/Linux 5.0 (32-bit)</para>
- <para>Extractable: no</para>
- <para>Password Enabled: no</para>
- <para>Public: no</para>
- <para>Featured: no</para>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </listitem>
- </orderedlist>
- </listitem>
- <listitem><para>Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful</para></listitem>
- <listitem><para><emphasis role="bold">WARNING</emphasis>: 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.</para></listitem>
- <listitem><para>Stop all Usage Servers if running. Run this on all Usage Server hosts.</para>
- <programlisting># service cloud-usage stop</programlisting></listitem>
- <listitem><para>Stop the Management Servers. Run this on all Management Server hosts.</para>
- <programlisting># service cloud-management stop</programlisting></listitem>
- <listitem><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.</para>
- <para>In the following commands, it is assumed that you have set the root password on the database, which is a &PRODUCT; recommended best practice. Substitute your own MySQL root password.</para>
- <programlisting># mysqldump -u root -p<mysql_password> cloud >> cloud-backup.dmp
-# mysqldump -u root -p<mysql_password> cloud_usage > cloud-usage-backup.dmp
-</programlisting>
- </listitem>
- <listitem><para>Download &PRODUCT; 3.0.4 onto management server host where it will run. Get the software from the following link:</para>
- <para><ulink url="https://www.citrix.com/English/ss/downloads/"></ulink></para>
- <para> You need a <ulink url="http://www.citrix.com/lang/English/publicindex.asp?destURL=%2FEnglish%2FmyCitrix%2Findex.asp%3F#">My Citrix Account</ulink>.</para></listitem>
- <listitem><para>Upgrade the &PRODUCT; packages. You should have a file in the form of
- “CloudStack-3.0.4-N-OSVERSION.tar.gz”. Untar the file, then run the install.sh script inside it. Replace the file and directory names below with those you are using:
- </para><programlisting># tar xzf CloudStack-3.0.4-N-OSVERSION.tar.gz
-# cd CloudStack-3.0.4-N-OSVERSION
-# ./install.sh
-</programlisting>
- <para>You should see a few messages as the installer prepares, followed by a list of choices.</para></listitem>
- <listitem><para>Choose "U" to upgrade the package</para><programlisting>>U</programlisting><para>You should see some output as the upgrade proceeds, ending with a message like "Complete! Done."</para></listitem>
- <listitem><para>If you have made changes to your existing copy of the file components.xml in your previous-version &PRODUCT; 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 3.0.4.</para>
- <note><para>How will you know whether you need to do this? If the upgrade output in the previous step included a message like "warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew", then some custom content was found in your old components.xml, and you need to merge the two files:</para></note>
- <orderedlist numeration="loweralpha">
- <listitem><para>Make a backup copy of your /etc/cloud/management/components.xml file. For example:</para>
- <programlisting># mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup</programlisting></listitem>
- <listitem><para>Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml:</para>
- <programlisting># cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml</programlisting></listitem>
- <listitem><para>Merge your changes from the backup file into the new components.xml file.</para><programlisting># vi /etc/cloud/management/components.xml</programlisting></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>If you have made changes to your existing copy of the /etc/cloud/management/db.properties file in your previous-version &PRODUCT; 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 3.0.4.</para>
- <orderedlist>
- <listitem><para>Make a backup copy of your file /etc/cloud/management/db.properties. For example:</para>
- <programlisting># mv /etc/cloud/management/db.properties /etc/cloud/management/db.properties-backup</programlisting></listitem>
- <listitem><para>Copy /etc/cloud/management/db.properties.rpmnew to create a new /etc/cloud/management/db.properties:</para>
- <programlisting># cp -ap /etc/cloud/management/db.properties.rpmnew etc/cloud/management/db.properties</programlisting></listitem>
- <listitem><para>Merge your changes from the backup file into the new db.properties file.</para>
- <programlisting># vi /etc/cloud/management/db.properties</programlisting></listitem>
- </orderedlist>
- </listitem>
- <listitem><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.</para>
- <programlisting># cloud-setup-encryption -e <encryption_type> -m <management_server_key> -k <database_key></programlisting>
- <para>When used without arguments, as in the following example, the default encryption type and keys will be used:</para>
- <itemizedlist>
- <listitem><para>(Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.</para></listitem>
- <listitem><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</para></listitem>
- <listitem><para>(Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the &PRODUCT; database. Default: password. It is highly recommended that you replace this with a more secure value.</para></listitem>
- </itemizedlist>
- </listitem>
- <listitem><para>Repeat steps 10 - 15 on every management server node. If you provided your own encryption key in step 15, use the same key on all other management servers.</para></listitem>
- <listitem><para>Start the first Management Server. Do not start any other Management Server nodes yet.</para>
- <programlisting># service cloud-management start</programlisting>
- <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.</para></listitem>
- <listitem><para>Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.</para>
- <programlisting># service cloud-usage start</programlisting></listitem>
- <listitem><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.</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Copy the CloudStack 3.0.4 .tgz download to the host, untar it, and cd into the resulting directory.</para></listitem>
- <listitem><para>Stop the running agent.</para>
- <programlisting># service cloud-agent stop</programlisting></listitem>
- <listitem><para>Update the agent software.</para><programlisting># ./install.sh</programlisting></listitem>
- <listitem><para>Choose "U" to update the packages.</para></listitem>
- <listitem><para>Start the agent.</para><programlisting># service cloud-agent start</programlisting></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>Log in to the &PRODUCT; 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.</para>
- <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.</para></listitem>
- <listitem><para>Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Run the command once on one management server. Provide the IP address of the MySQL instance, the MySQL user name, and the database password for that user. In addition to those parameters, provide the "-a" argument. For example:</para>
- <programlisting># nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -a > sysvm.log 2>&1 &</programlisting>
- <para>This might take up to an hour or more to run, depending on the number of accounts in the system.</para>
- </listitem>
- <listitem><para>After the script terminates, check the log to verify correct execution:</para>
- <programlisting># tail -f sysvm.log</programlisting>
- <para>The content should be like the following:</para>
- <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).
- </programlisting>
- </listitem>
- </orderedlist>
- </listitem>
- <listitem><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.</para>
- <para>Use one of the following techniques, depending on the hypervisor.</para>
- <formalpara>
- <title>XenServer or KVM:</title>
- <para>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.</para>
- </formalpara><para>Run the following commands on the XenServer or KVM host on which the system VM is present:</para>
- <programlisting># ssh -i <private-key-path> <link-local-ip> -p 3922
-# cat /etc/cloudstack-release</programlisting><para>The output should be like the following:</para>
- <programlisting>Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012</programlisting>
- <formalpara>
- <title>ESXi</title>
- <para>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.</para>
- </formalpara><para>Run the following commands on the Management Server:</para><programlisting># ssh -i <private-key-path> <private-ip> -p 3922
-# cat /etc/cloudstack-release
-</programlisting><para>The output should be like the following:</para>
- <programlisting>Cloudstack Release 3.0 Mon Feb 6 15:10:04 PST 2012</programlisting></listitem>
- <listitem>
- <para>In order to deploy AWS API on its new port (7080), you need to deploy it under a separate webapps folder.</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Create the new webapps folder:</para>
- <programlisting># mkdir -p /usr/share/cloud/management/webapps7080</programlisting>
- </listitem>
- <listitem><para>Create a symbolic link:</para>
- <programlisting># ln -s /usr/share/cloud/bridge/webapps/awsapi /usr/share/cloud/management/webapps7080/awsapi</programlisting>
- </listitem>
- <listitem><para>Remove the old folder:</para>
- <programlisting># rm /usr/share/cloud/management/webapps/awsapi</programlisting>
- </listitem>
- <listitem><para>Open port 7080:</para>
- <programlisting># iptables -I INPUT -p tcp -m tcp --dport 7080 -j ACCEPT</programlisting>
- </listitem>
- <listitem><para>If you have made any modifications in server.xml on your existing &PRODUCT; installation, back it up:</para>
- <programlisting># mv /etc/cloud/management/server.xml /etc/cloud/management/server.xml-backup</programlisting>
- <para>Then replace with the new server.xml file:</para>
- <programlisting># cp /etc/cloud/management/server.xml.rpmnew /etc/cloud/management/server.xml</programlisting>
- <para>Merge any changes from the backup file into the new server.xml file.</para>
- <programlisting># vi /etc/cloud/management/server.xml</programlisting>
- </listitem>
- <listitem><para>Open the /etc/cloud/management/ec2.service.properties file in your favorite editor. For example:</para>
- <programlisting># vi /etc/cloud/management/ec2.service.properties</programlisting>
- <para>Add the following to specify the Management Server host and port to which AWS API calls should be forwarded.</para>
- <programlisting>
-managementServer=<management.server.IP.address>
-cloudAPIPort=8080
- </programlisting>
- </listitem>
- <listitem><para>Restart the Management Server to put the new settings into effect.</para></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by &PRODUCT; 3.0.4. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the &PRODUCT; 3.0.3 Advanced Installation Guide.</para></listitem>
- <listitem><para>Now apply the XenServer hotfix XS602E003 to XenServer v6.0.2 hypervisor hosts. (Support for this hotfix is the reason for release 3.0.4.)</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Disconnect the XenServer cluster from &PRODUCT;.</para>
- <para>In the left navigation bar of the &PRODUCT; UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage.</para>
- <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.</para>
- <para>Wait until the status of the cluster has reached Unmanaged. Use the &PRODUCT; UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster.</para>
- </listitem>
- <listitem><para>To clean up the VLAN, log in to one XenServer host and run:</para>
- <programlisting>/opt/xensource/bin/cloud-clean-vlan.sh</programlisting>
- </listitem>
- <listitem>
- <para>Now prepare the upgrade by running the following on one XenServer host:</para>
- <programlisting>/opt/xensource/bin/cloud-prepare-upgrade.sh</programlisting>
- <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.</para>
- </listitem>
- <listitem><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. </para>
- <para>On the Xen pool master, upload the hotfix with this command:</para>
- <programlisting>xe patch-upload file-name=XS602E003.xsupdate</programlisting>
- <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.</para>
- <note><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.</para></note>
- </listitem>
- <listitem><para>Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host:</para>
- <programlisting># xe vm-list</programlisting>
- <para>Then use this command to migrate each VM. Replace the example host name and VM name with your own:</para>
- <programlisting># xe vm-migrate live=true host=<host-name> vm=<VM-name></programlisting>
- <para><emphasis role="bold">Troubleshooting:</emphasis> 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 /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14.</para>
- </listitem>
- <listitem><para>Apply the hotfix. First, get the UUID of this host:</para>
- <programlisting># xe host-list</programlisting>
- <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.
- </para>
- <programlisting>xe patch-apply host-uuid=<host-uuid> uuid=<hotfix-uuid></programlisting>
- </listitem>
- <listitem><para>Copy the following files from the &PRODUCT; Management Server to the host.</para>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Copy from here...</para></entry>
- <entry><para>...to here</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py</para></entry>
- <entry><para>/opt/xensource/sm/NFSSR.py</para></entry>
- </row>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/setupxenserver.sh</para></entry>
- <entry><para>/opt/xensource/bin/setupxenserver.sh</para></entry>
- </row>
- <row>
- <entry><para>/usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/make_migratable.sh</para></entry>
- <entry><para>/opt/xensource/bin/make_migratable.sh</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </listitem>
- <listitem><para>Reboot this XenServer host.</para></listitem>
- <listitem><para>Run the following:</para>
- <programlisting>/opt/xensource/bin/setupxenserver.sh</programlisting>
- <note><para>If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it.</para></note>
- </listitem>
- <listitem><para>Run the following:</para>
- <programlisting>for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; </programlisting>
- </listitem>
- <listitem><para>On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs."</para></listitem>
- </orderedlist>
- </listitem>
- </orderedlist>
- </section>
- <section id="upgrade-from-2.1.x-to-3.0.4">
- <title>Upgrade from 2.1.x to 3.0.4</title>
- <para>Direct upgrades from version 2.1.0 - 2.1.10 to 3.0.4 are not supported. It must first be upgraded to version 2.2.14. For information on how to upgrade from 2.1.x to 2.2.14, see the version 2.2.14 Release Notes.</para>
- </section>
- </chapter>
- <chapter id="version-3.0.4">
- <title>Version 3.0.4</title>
- <para></para>
- <section id="what-new-in-3.0.4">
- <title>What’s New in 3.0.4</title>
- <para>&PRODUCT; 3.0.4 is the first maintenance patch for &PRODUCT; 3.0.3. This release includes no new features. For a list of the major fixed items, see Issues Fixed in 3.0.4.</para>
- </section>
- <section id="issues-fixed-3.0.4">
- <title>Issues Fixed in 3.0.4</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para></para></entry>
- <entry><para></para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-15376, CS-15373</para></entry>
- <entry><para>The AWS APIs (EC2 and S3) now listen on the 7080 port and send request to CloudStack on the 8080 port just as any other clients of CloudStack.</para></entry>
- </row>
- <row>
- <entry><para>CS-13944</para></entry>
- <entry><para>The &PRODUCT; 2.2.x to 3.0.x database upgrade for multiple physical networks is now supported.</para></entry>
- </row>
- <row>
- <entry><para>CS-15300</para></entry>
- <entry><para>The admin accounts of a domain now honour the limits imposed on that domain just like the regular accounts do. A domain admin now is not allowed to create an unlimited number of instances, volumes, snapshots, and so on.</para></entry>
- </row>
- <row>
- <entry><para>CS-15396</para></entry>
- <entry><para>The &PRODUCT; database now contain the UUD information after the 2.2.14 to 3.0.4 upgrade.</para></entry>
- </row>
- <row>
- <entry><para>CS-15450</para></entry>
- <entry><para>Upgrade from 2.2.14 to 3.0.4 no longer fails on a VMware host.</para></entry>
- </row>
- <row>
- <entry><para>CS-15449</para></entry>
- <entry><para>Running cloudstack-aws-api-register no longer fails with the "User registration failed with error: [Errno 113] No route to host" error.</para></entry>
- </row>
- <row>
- <entry><para>CS-15455</para></entry>
- <entry><para>The iptable rules are configured to open the awsapi port (7080) as part of the installation.</para></entry>
- </row>
- <row>
- <entry><para>CS-15429</para></entry>
- <entry><para>While creating an instance with data volume, disk offering also is considered while checking the account limit on volume resources.</para></entry>
- </row>
- <row>
- <entry><para>CS-15414</para></entry>
- <entry><para>After the 2.2.14 to 3.0.4 upgrade, the value of the global parameter xen.guest.network.device is now decrypted before setting the traffic label.</para></entry>
- </row>
- <row>
- <entry><para>CS-15382</para></entry>
- <entry><para>During 2.2.14 to 3.0.4 upgrade, the hosts no longer go to the Alert state if destroyed networks existed with non-existent tags prior to upgrade.</para></entry>
- </row>
- <row>
- <entry><para>CS-15323</para></entry>
- <entry><para>&PRODUCT; supports the following Citrix XenServer hotfixes: XS602E003, XS602E004, and
- XS602E005.</para></entry>
- </row>
- <row>
- <entry><para>CS-15430</para></entry>
- <entry><para>Create snapshot now fails if creating a snapshot exceeds the snapshot resource limit for a domain admin or a user account.</para></entry>
- </row>
- <row>
- <entry><para></para></entry>
- <entry><para></para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="known-issues-3.0.4">
- <title>Known Issues in 3.0.4</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Issue ID</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-15476</para></entry>
- <entry><para>The 2.2.14 to 3.0.4 upgrade fails if multiple untagged physical networks exist before the upgrade.</para></entry>
- </row>
- <row>
- <entry><para>CS-15407</para></entry>
- <entry><para>After the 2.2.14 to 3.0.4 upgrade, VLAN allocation on multiple physical networks does not happen as expected.</para>
- <para>To workaround this issue, follow the instructions given below:</para>
- <orderedlist>
- <listitem><para>Revert to your 2.2.14 setup.</para></listitem>
- <listitem><para>Stop all the VMs with the isolated virtual networks in your cloud setup.</para></listitem>
- <listitem><para> Run following query to find if any networks still have the NICs allocated:</para>
- <orderedlist numeration="loweralpha">
- <listitem><para>Check if any virtual guest networks have the NICs allocated:</para>
- <programlisting>#SELECT DISTINCT op.id from `cloud`.`op_networks` op JOIN `cloud`.`networks` n on op.id=n.id WHERE nics_count != 0 AND guest_type = 'Virtual'; </programlisting></listitem>
- <listitem><para>If this returns any network IDs, then ensure the following:</para>
- <orderedlist numeration="lowerroman">
- <listitem><para>All the VMs are stopped.</para></listitem>
- <listitem><para>No new VM is started.</para></listitem>
- <listitem><para>Shutdown the Management Server.</para></listitem>
- </orderedlist></listitem>
- <listitem><para>Remove the NICs count for the virtual network IDs returned in step (a), and set the NIC count to 0:</para>
- <programlisting>UPDATE `cloud`.`op_networks` SET nics_count = 0 WHERE id = <enter id of virtual network></programlisting></listitem>
- <listitem><para>Restart the Management Server, and wait for all the networks to shut down.</para>
- <note><para>Networks shutdown is determined by the network.gc.interval and network.gc.wait parameters.</para></note></listitem>
- </orderedlist>
- </listitem>
- <listitem><para>Ensure that all the networks are shut down and all the guest VNETs are free.</para></listitem>
- <listitem><para>Run the upgrade script.</para><para>This allocates all your guest VNET ranges to the first physical network.</para></listitem>
- <listitem><para>By using the updatePhysicalNetwork API, reconfigure the VNET ranges for each physical network as desired.</para></listitem>
- <listitem><para>Start all the VMs.</para></listitem>
- </orderedlist>
- </entry>
- </row>
- <row>
- <entry><para>CS-14680</para></entry>
- <entry><para>CloudStack and LDAP user validation cannot happen simultaneously because the user password is hashed and stored in the database, and LDAP requires the passwords in plain text.</para>
- <para>To work with the LDAP user, the MD5 hash should be disabled in the login process by commenting the following variable in sharedFunctions.js file available at /usr/share/cloud/management/webapps/client/scripts, and restart the cloud-management service.</para>
- <programlisting>var md5HashedLogin = false;</programlisting><para>However, if md5HashedLogin is set to false, the end user can login with the LDAP credentials
- but not with the &PRODUCT; user credentials.</para></entry>
- </row>
- <row>
- <entry><para>CS-15578</para></entry>
- <entry><para>Upgrade from 2.2.14 to 3.04 fails with an exception if the setup has a zone deleted and the
- corresponding router state removed.</para>
- <para>To workaround this issue, perform the following before upgrading from 2.2.x to 3.0.4:</para>
- <programlisting># mysql> delete dr from domain_router dr, vm_instance vi, data_center dc where dr.id = vi.id and vi.data_center_id = dc.id and dc.removed is not null; </programlisting></entry>
- </row>
- <row>
- <entry><para></para></entry>
- <entry><para></para></entry>
- </row>
- <row>
- <entry><para></para></entry>
- <entry><para></para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- </chapter>
- <chapter id="version-3.0.3">
- <title>Version 3.0.3</title>
- <para></para>
- <section id="what-new-in-3.0.3">
- <title>What's New in 3.0.3</title>
- <para></para>
- <section id="secure-console-access-on-xenserver">
- <title>Secure Console Access on XenServer</title>
- <para>With the addition of Secure Console feature, users can now securely access the VM consoles on the XenServer hypervisor. You can either SSH or use the View Console option in the Management Server to securely connect to the VMs on the XenServer host. The Management Server uses the xapi API to stream the VM consoles. However, there is no change in the way you can access the console of a VM. This feature is supported on XenServer 5.6 and 6.0 versions.</para>
- </section>
- <section id="release-note-stopped-vm">
- <title>Stopped VM</title>
- <para>This release supports creating VMs without starting them on the backend. You can determine whether the VM needs to be started as part of the VM deployment. A VM can be deployed in two ways: create and start a VM (the default method); create a VM and leave it in the stopped state.</para>
- <para>A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are:</para>
- <itemizedlist>
- <listitem><para>true - The VM starts as a part of the VM deployment</para></listitem>
- <listitem><para>false - The VM is left in stopped state at the end of the VM deployment</para></listitem>
- </itemizedlist>
- </section>
- <section id="release-note-upload-existing-volume-to-vm">
- <title>Uploading an Existing Volume to a Virtual Machine</title>
- <para>Existing data can now be made accessible to a virtual machine. This is called uploading a volume to the VM. For example, this is useful to upload data from a local file system and attach it to a VM. Root administrators, domain administrators, and end users can all upload existing volumes to VMs. The upload is performed by using HTTP. The uploaded volume is placed in the zone's secondary storage.</para>
- <para>This functionality is supported for the following hypervisors:</para>
- <itemizedlist>
- <listitem><para>Hypervisor : Disk Image Format</para></listitem>
- <listitem><para>XenServer : VHD</para></listitem>
- <listitem><para>VMware : OVA</para></listitem>
- <listitem><para>KVM : QCOW2</para></listitem>
- <listitem><para>OVM : RAW</para></listitem>
- </itemizedlist>
- </section>
- <section id="dedicated-ha-hosts">
- <title>Dedicated High-Availability Hosts</title>
- <para>One or more hosts can now be designated for use only by high-availability (HA) enabled VMs that are restarted due to a host failure. Setting up a pool of such dedicated HA hosts as the recovery destination for all HA-enabled VMs make it easier to determine which VMs are restarted as part of the high-availability function. You can designate a host as a dedicated-HA restart node only if the Dedicated HA Hosts feature is enabled by setting the appropriate global configuration parameter.</para>
- </section>
- <section id="support-for-aws-api">
- <title>Support for Amazon Web Services API</title>
- <para>This release supports Amazon Web Services APIs, including Elastic Compute Cloud (EC2) API. Fidelity with the EC2 API and the installation experience for this functionality are both enhanced. In prior releases, users were required to install a separate component called CloudBridge, in addition to installing the Management Server. For new installations of &PRODUCT; 3.0.3, this software is installed automatically along with &PRODUCT; and runs in a more closely integrated fashion. The feature is disabled by default, but can be easily enabled by setting the appropriate global configuration parameter and performing a few setup steps.</para>
- </section>
- <section id="support-nexus-dvswitch">
- <title>Support for Cisco Nexus 1000v Virtual Switch</title>
- <para>In addition to standard vSwitch, Cisco Nexus 1000v is now supported for virtual network configuration in VMware vSphere deployments. With this, guest traffic isolation through VLANs is possible in VMware environment. Using Nexus virtual switch simplifies configuring and monitoring virtual networks that span across a large number of hosts, and facilitates live migration in VMWare-based cloud deployment.</para>
- </section>
- </section>
- <section id="summary-features-by-defect-no">
- <title>Summary of New Features by Bug Number</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Issue ID</para></entry>
- <entry><para>Feature</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-14385</para></entry>
- <entry><para>Dedicated High Availability Host</para></entry>
- </row>
- <row>
- <entry><para>CS-14378</para></entry>
- <entry><para>Stopped VM</para></entry>
- </row>
- <row>
- <entry><para>CS-10789</para></entry>
- <entry><para>Uploading an Existing Volume to a Virtual Machine</para></entry>
- </row>
- <row>
- <entry><para>CS-6061</para></entry>
- <entry><para>Secure Console Access on XenServer</para></entry>
- </row>
- <row>
- <entry><para>CS-9909</para></entry>
- <entry><para>Cisco Nexus 1000v Support</para></entry>
- </row>
- <row>
- <entry><para>CS-14435</para></entry>
- <entry><para>Support for Amazon Web Services API</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="issues-fixed-in-3.0.3">
- <title>Issues Fixed in 3.0.3</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Defects</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-14256</para></entry>
- <entry><para>Virtual Router no longer remains in starting state for subdomain or user on a KVM 3.0.1 prerlease host on RHEL 6.2.</para></entry>
- </row>
- <row>
- <entry><para>CS-7495</para></entry>
- <entry><para>Implemented a variety of Xen management host improvements.</para></entry>
- </row>
- <row>
- <entry><para>CS-8105</para></entry>
- <entry><para>NFS v4 for primary storage now works as expected on KVM hosts.</para></entry>
- </row>
- <row>
- <entry><para>CS-9989</para></entry>
- <entry><para>The error messages returned during VM deployment failure will have much more details than before.</para></entry>
- </row>
- <row>
- <entry><para>CS-12584</para></entry>
- <entry><para>You can no longer add security groups not supported by the hypervisor in use.</para></entry>
- </row>
- <row>
- <entry><para>CS-12705</para></entry>
- <entry><para>When creating a Network offering by using SRX as the service provider for SourceNAT servcies, an option is given in the &PRODUCT; UI now to set the source_nat type to "per Zone"/"per account". </para></entry>
- </row>
- <row>
- <entry><para>CS-12782</para></entry>
- <entry><para>Assigning a VM from Basic to Advanced zone no longer ignores the network ID. A warning message is displayed for VM movements across zones.</para></entry>
- </row>
- <row>
- <entry><para>CS-12591</para></entry>
- <entry><para>Broadcast Address on the Second Public IP NIC is now corrected.</para></entry>
- </row>
- <row>
- <entry><para>CS-13272</para></entry>
- <entry><para>When a user is deleted, all the associated properties, such as IPs and virtual routers, are now deleted.</para></entry>
- </row>
- <row>
- <entry><para>CS-13377</para></entry>
- <entry><para>Creating template from a root disk of a stopped instance now provides an option to make it a "Featured template".</para></entry>
- </row>
- <row>
- <entry><para>CS-13500</para></entry>
- <entry><para>Reaching the first guest VM by using its public IP from the second guest VM no longer fails.</para></entry>
- </row>
- <row>
- <entry><para>CS-13853</para></entry>
- <entry><para>The default gateway can no longer be 0.0.0.0 in the Secondary Storage VM (SSVM).</para></entry>
- </row>
- <row>
- <entry><para>CS-13863</para></entry>
- <entry><para>The queryAsyncJobResult command in XML format now returns the correct UUIDs.</para></entry>
- </row>
- <row>
- <entry><para>CS-13867</para></entry>
- <entry><para>Corrected CSP xenserver-cloud-supp.tgz for XenServer 5.6 and 6.0.</para></entry>
- </row>
- <row>
- <entry><para>CS-13904</para></entry>
- <entry><para>Labels and values for the service offerings CPU and memory are now consistent. </para></entry>
- </row>
- <row>
- <entry><para>CS-13998</para></entry>
- <entry><para>The SSVM kernel panic issue is fixed on XenServer.</para></entry>
- </row>
- <row>
- <entry><para>CS-14090</para></entry>
- <entry><para>The issue is fixed where running the VMware snapshots randomly fails with the ArrayIndexOutOfBoundsException error.</para></entry>
- </row>
- <row>
- <entry><para>CS-14021</para></entry>
- <entry><para>The java.lang.OutOfMemoryError is fixed on the Management Server.</para></entry>
- </row>
- <row>
- <entry><para>CS-14025</para></entry>
- <entry><para>The Python Eggs are provided to easily package the test client for each branch of &PRODUCT;.</para></entry>
- </row>
- <row>
- <entry><para>CS-14068</para></entry>
- <entry><para>Resetting the VM password through the &PRODUCT; UI no longer causes any error.</para></entry>
- </row>
- <row>
- <entry><para>CS-14156</para></entry>
- <entry><para>The pod which has the administrator's virtual router is no longer selected while creating the virtual routers for guests.</para></entry>
- </row>
- <row>
- <entry><para>CS-14182</para></entry>
- <entry><para>The users can now delete their ISOs as normal users.</para></entry>
- </row>
- <row>
- <entry><para>CS-14185</para></entry>
- <entry><para>The listOSTypes API now filters out the types of operating system by using the keywords.</para></entry>
- </row>
- <row>
- <entry><para>CS-14204</para></entry>
- <entry><para>The cloud-setup-bonding.sh command no longer generates the "command not found" error.</para></entry>
- </row>
- <row>
- <entry><para>CS-14214</para></entry>
- <entry><para>The Specify VLAN option cannot be enabled now for an isolated Network offering with SourceNAT enabled.</para></entry>
- </row>
- <row>
- <entry><para>CS-14234</para></entry>
- <entry><para>Sending project invite email to an account now requires SMTP configured in &PRODUCT;.</para></entry>
- </row>
- <row>
- <entry><para>CS-14237</para></entry>
- <entry><para>The garbage collector of the primary storage no longer fails when the first host in the cluster is not up.</para></entry>
- </row>
- <row>
- <entry><para>CS-14241</para></entry>
- <entry><para>Custom Volume Disk Offering is now matching the Global configuration value.</para></entry>
- </row>
- <row>
- <entry><para>CS-14270</para></entry>
- <entry><para>The listNetworks API no longer assumes that the broadcast type is always VLAN.</para></entry>
- </row>
- <row>
- <entry><para>CS-14319</para></entry>
- <entry><para>The internal name of the VM is no longer present in the error message that is displayed to a domain administrator.</para></entry>
- </row>
- <row>
- <entry><para>CS-14321</para></entry>
- <entry><para>The listVolumes API call now returns a valid value for the isExtractable parameter for the ISO-derived disk and data disk volumes.</para></entry>
- </row>
- <row>
- <entry><para>CS-14323</para></entry>
- <entry><para>Invalid API calls will now give valid response in json/xml format.</para></entry>
- </row>
- <row>
- <entry><para>CS-14339</para></entry>
- <entry><para>Custom Disk Size will now allow values larger than 100GB.</para></entry>
- </row>
- <row>
- <entry><para>CS-14357</para></entry>
- <entry><para>The ConsoleProxyLoadReportCommand is no longer fired continuously.</para></entry>
- </row>
- <row>
- <entry><para>CS-14421</para></entry>
- <entry><para>Fixed the issue of virtual router deployments. The DHCP entries can now be assigned to the router.</para></entry>
- </row>
- <row>
- <entry><para>CS-14555</para></entry>
- <entry><para>Unzipped downloaded template MD5SUM will no longer override the zipped template MD5SUM in the database.</para></entry>
- </row>
- <row>
- <entry><para>CS-14598</para></entry>
- <entry><para>The complete screen of the running VM is now displayed in the console proxy.</para></entry>
- </row>
- <row>
- <entry><para>CS-14600</para></entry>
- <entry><para>Windows or Linux based consoles are no longer lost upon rebooting VMs.</para></entry>
- </row>
- <row>
- <entry><para>CS-14784</para></entry>
- <entry><para>Multiple subnets with the same VLAN now work as expected.</para></entry>
- </row>
- <row>
- <entry><para>CS-13303, 14874, 13897, 13944, 14088, 14190</para></entry>
- <entry><para>A variety of upgrade issues have been fixed in release 3.0.3.</para></entry>
- </row>
- <row>
- <entry><para>CS-15080</para></entry>
- <entry><para>Setting a private network on a VLAN for VMWare environment is now supported.</para></entry>
- </row>
- <row>
- <entry><para>CS-15168</para></entry>
- <entry><para>The console proxy now works as expected and no exception is shown in the log after upgrading from version 2.2.14 to 3.0.2.</para></entry>
- </row>
- <row>
- <entry><para>CS-15172</para></entry>
- <entry><para>Version 3.0.2 now accepts the valid public key.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="known-issues-3.0.3">
- <title>Known Issues in 3.0.3</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Defects</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-14346</para></entry>
- <entry><para>The UpdateVirtualMachine API call does not check whether the VM is stopped. Therefore, stop the VM manually before issuing this call.</para></entry>
- </row>
- <row>
- <entry><para>CS-14361</para></entry>
- <entry><para>On KVM hosts, the volume size allocated in primary storage is stored incorrectly in the database or displayed incorrectly in the Dashboard. The value displayed in the Dashboard is very small compared to the original size.</para></entry>
- </row>
- <row>
- <entry><para>CS-14452</para></entry>
- <entry><para>Data disk volumes are not automatically copied from one cluster to another.</para></entry>
- </row>
- <row>
- <entry><para>CS-14770</para></entry>
- <entry><para>The API does not return the keypair information when a VM is deployed with sshkey. This affects the API commands related to virtual machines (deployVirtualMachine, listVirtualMachines, ... *VirtualMachine), as well as the corresponding AWS APIs.</para></entry>
- </row>
- <row>
- <entry><para>CS-14780</para></entry>
- <entry><para>You are allowed to ping the elastic IP address of the VM even though no ingress rule is set that allows the ICMP protocol.</para></entry>
- </row>
- <row>
- <entry><para>CS-14796</para></entry>
- <entry><para>Deploying a VM is allowed even if the user data is not Base 64 encoded. Using the ec2-run-instances API with -d or -f option with user data in plain does not return any error.</para></entry>
- </row>
- <row>
- <entry><para>CS-14879</para></entry>
- <entry><para>When a user VM is stopped or terminated, the static NAT associated with this VM is not disabled. This public IP address is still owned by this account and cannot be associated to any other user VM.</para></entry>
- </row>
- <row>
- <entry><para>CS-14939</para></entry>
- <entry><para>Adding a VMware cluster is not supported when the Management Network is migrated to the Distributed Virtual Switch environment.</para></entry>
- </row>
- <row>
- <entry><para>CS-14952</para></entry>
- <entry><para>The vCenter IP Address and the datacenter information is not present in the "virtual_supervisor_module" table. The Nexus virtual switch credentials are not encrypted.</para></entry>
- </row>
- <row>
- <entry><para>CS-15009</para></entry>
- <entry><para>The port_profile table will not be populated with port profile information. In this release, &PRODUCT; directly connects to the VSM for all the port profile operations; therefore, no port profile information is cached.</para></entry>
- </row>
- <row>
- <entry><para>CS-15037</para></entry>
- <entry><para>Hairpin NAT is not supported when NetScaler is used for EIP.</para></entry>
- </row>
- <row>
- <entry><para>CS-15092</para></entry>
- <entry><para>Connecting to the guest VMs through SSH is extremely slow, and it results in connection timeout.</para></entry>
- </row>
- <row>
- <entry><para>CS-15105</para></entry>
- <entry><para>The cloud-sysvmadm script does not work if the integration.api.port parameter is set to any port other than 8096.</para></entry>
- </row>
- <row>
- <entry><para>CS-15117</para></entry>
- <entry><para>In a deployment with Nexus 1000v virtual switch, disable/enable operation of the Nexus virtual switch is not working as expected. The Nexus 1000v virtual switch continues to be used to create network or edit network operations even after disabling the switch.</para></entry>
- </row>
- <row>
- <entry><para>CS-15118</para></entry>
- <entry><para>In a deployment with Nexus 1000v virtual switch, zone VLAN range is not validated against the reserved list of VLANs for Nexus 1000v.</para></entry>
- </row>
- <row>
- <entry><para>CS-15120</para></entry>
- <entry><para>No actions are listed in the Action column of the Volumes page in the &PRODUCT; UI.</para></entry>
- </row>
- <row>
- <entry><para>CS-15124</para></entry>
- <entry><para>Mixed switch environment is not supported. The zone can either be deployed as Standard vSwitch based or Nexus virtual switch based.</para></entry>
- </row>
- <row>
- <entry><para>CS-15163</para></entry>
- <entry><para>The minimum limit is not honored when there is not enough capacity to deploy all the VMs and the ec2-run-instances command with the -n >n1 -n2> option is used to deploy multiple VMs.</para></entry>
- </row>
- <row>
- <entry><para>CS-15167</para></entry>
- <entry><para>The Amazon Web Services API does not allow the admin user to view or act on the resources owned by the regular users.</para></entry>
- </row>
- <row>
- <entry><para>CS-15198</para></entry>
- <entry><para>Peak bandwidth (PIR) and burst size shaping policies are not applied on Nexus 1000v virtual switch interface.</para></entry>
- </row>
- <row>
- <entry><para>CS-15256</para></entry>
- <entry><para>If cluster addition fails in a zone using the Cisco Nexus 1000v virtual switch, a subsequent retry will not succeed in adding the cluster. To work around:</para>
- <orderedlist>
- <listitem><para>Find the VSM id that was attempted to be added along with the cluster when the cluster creation failed. To do this, log into the MySQL database and execute a select query: </para>
- <programlisting># mysql -uroot -p <password_for_mysql_db>;
-mysql> use cloud;
-mysql> select id from `cloud`.`virtual_supervisor_module` where ipaddr="<vsm_ipaddress>";
-</programlisting></listitem>
- <listitem><para>Delete the cluster to VSM mapping in the cluster_vsm_map table for this vsm id: </para><programlisting>mysql> delete from `cloud`.`virtual_supervisor_module` where vsm_id=<the id returned in step1>; </programlisting></listitem>
- <listitem><para>Try again to add the cluster.</para></listitem>
- </orderedlist>
- </entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="api-changes-from-3.0.2-to-3.0.3">
- <title>API Changes from 3.0.2 to 3.0.3</title>
- <para></para>
- <section id="new-api-commands-3.0.3">
- <title>New API Commands</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>API Commands</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>listCiscoNexusVSMs</para></entry>
- <entry><para>Retrieves information of a Cisco Nexus 1000v virtual switch associated with a cluster. It lists the control VLAN ID, packet VLAN ID, and data VLAN ID, as well as the IP address of the Nexus virtual switch.</para></entry>
- </row>
- <row>
- <entry><para>enableCiscoNexusVSM</para></entry>
- <entry><para>Enables a Cisco Nexus VSM device.</para></entry>
- </row>
- <row>
- <entry><para>disableCiscoNexusVSM</para></entry>
- <entry><para>Disables a Cisco Nexus VSM device.</para></entry>
- </row>
- <row>
- <entry><para>deleteCiscoNexusVSM</para></entry>
- <entry><para>Deletes a Cisco Nexus VSM device.</para></entry>
- </row>
- <row>
- <entry><para>markDefaultZoneForAccount</para></entry>
- <entry><para>Marks a default zone for the current account.</para></entry>
- </row>
- <row>
- <entry><para>uploadVolume</para></entry>
- <entry><para>Uploads a data disk.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="changed-api-commands">
- <title>Changed API Commands</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>API Commands</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>reconnectHost</para></entry>
- <entry><para>A new response parameter is added: hahost.</para></entry>
- </row>
- <row>
- <entry><para>addCluster</para></entry>
- <entry><para>The following request parameters are added:</para>
- <itemizedlist>
- <listitem><para>vsmipaddress (optional)</para></listitem>
- <listitem><para>vsmpassword (optional)</para></listitem>
- <listitem><para>vsmusername (optional)</para></listitem>
- </itemizedlist>
- <para>The following parameter is made mandatory: podid</para>
- </entry>
- </row>
- <row>
- <entry><para>listVolumes</para></entry>
- <entry><para>A new response parameter is added: status</para></entry>
- </row>
- <row>
- <entry><para>migrateVolume</para></entry>
- <entry><para>A new response parameter is added: status</para></entry>
- </row>
- <row>
- <entry><para>prepareHostForMaintenance</para></entry>
- <entry><para>A new response parameter is added: hahost.</para></entry>
- </row>
- <row>
- <entry><para>addSecondaryStorage</para></entry>
- <entry><para>A new response parameter is added: hahost.</para></entry>
- </row>
- <row>
- <entry><para>enableAccount</para></entry>
- <entry><para>A new response parameter is added: defaultzoneid</para></entry>
- </row>
- <row>
- <entry><para>attachVolume</para></entry>
- <entry><para>A new response parameter is added: status</para></entry>
- </row>
- <row>
- <entry><para>cancelHostMaintenance</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>addSwift</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>listSwifts</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>listExternalLoadBalancers</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>createVolume</para></entry>
- <entry><para>A new response parameter is added: status</para></entry>
- </row>
- <row>
- <entry><para>listCapabilities</para></entry>
- <entry><para>A new response parameter is added: customdiskofferingmaxsize</para></entry>
- </row>
- <row>
- <entry><para>disableAccount</para></entry>
- <entry><para>A new response parameter is added: defaultzoneid </para></entry>
- </row>
- <row>
- <entry><para>deployVirtualMachine</para></entry>
- <entry><para>A new request parameter is added: startvm (optional)</para></entry>
- </row>
- <row>
- <entry><para>deleteStoragePool</para></entry>
- <entry><para>A new request parameter is added: forced (optional)</para></entry>
- </row>
- <row>
- <entry><para>updateAccount</para></entry>
- <entry><para>A new response parameter is added: defaultzoneid</para></entry>
- </row>
- <row>
- <entry><para>addHost</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>updateHost</para></entry>
- <entry><para>A new response parameter is added: hahost</para></entry>
- </row>
- <row>
- <entry><para>detachVolume</para></entry>
- <entry><para>A new response parameter is added: status</para></entry>
- </row>
- <row>
- <entry><para>listAccounts</para></entry>
- <entry><para>A new response parameter is added: defaultzoneid</para></entry>
- </row>
- <row>
- <entry><para>listHosts</para></entry>
- <entry><para>A new response parameter is added: hahost</para><para>A new request parameter is added: hahost (optional)</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- </section>
- </chapter>
- <chapter id="version-3.0.2">
- <title>Version 3.0.2</title>
- <para></para>
- <section id="new-upgrade-path-3.0.2">
- <title>New Upgrade Path</title>
- <para>Starting with version 3.0.2, existing 2.2.x installations can be upgraded. See Upgrade from 2.2.x to 3.0.2.</para>
- </section>
- <section id="what-new-3.0.2">
- <title>What's New in 3.0.2</title>
- <para>Version 3.0.2 includes no new product features. However, the following changes were introduced in version 3.0.2.</para>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <tbody>
- <row>
- <entry><para>CS-14588</para></entry>
- <entry><para>When creating a virtual machine in the UI, the name of the VM specified will now directly affect its DNS name, unlike previous releases. DNS names can only be specified during creation. You can continue to modify the Display Name, but this will have no effect on the DNS name.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="issues-fixed-3.0.2">
- <title>Issues Fixed in 3.0.2</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Defect</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-13398</para></entry>
- <entry><para>Pressing ESC while in any UI dialog will no longer freeze the UI.</para></entry>
- </row>
- <row>
- <entry><para>CS-14305</para></entry>
- <entry><para>You can now upgrade the service offerings for system VMs.</para></entry>
- </row>
- <row>
- <entry><para>CS-14333</para></entry>
- <entry><para>Fixed an issue that prevented any users from upgrading their service offerings.</para></entry>
- </row>
- <row>
- <entry><para>CS-14341</para></entry>
- <entry><para>Fixed an issue where the orders of the service/disk offerings were not being honored in the UI.</para></entry>
- </row>
- <row>
- <entry><para>CS-14364</para></entry>
- <entry><para>Ubuntu 10.04 now works with the Quick Basic Install.</para></entry>
- </row>
- <row>
- <entry><para>CS-14369</para></entry>
- <entry><para>Quick Basic Install for KVM hypervisors can now be done on a single host.</para></entry>
- </row>
- <row>
- <entry><para>CS-14372</para></entry>
- <entry><para>Async Job timeout counter is now properly reset across calls.</para></entry>
- </row>
- <row>
- <entry><para>CS-14406</para></entry>
- <entry><para>Putting a host into maintenance will now properly live migrate the VM rather than stopping it.</para></entry>
- </row>
- <row>
- <entry><para>CS-14433</para></entry>
- <entry><para>Fixed an issue where System VMs were not correctly releasing their IP when destroyed.</para></entry>
- </row>
- <row>
- <entry><para>CS-14441</para></entry>
- <entry><para>VMWare: Networks labels are not correctly honored.</para></entry>
- </row>
- <row>
- <entry><para>CS-14447</para></entry>
- <entry><para>Registering an ISO/Template with “All Zones” will now correctly propagate the templates to all zones.</para></entry>
- </row>
- <row>
- <entry><para>CS-14447</para></entry>
- <entry><para>Deleting an account will now properly remove its associated Virtual Router.</para></entry>
- </row>
- <row>
- <entry><para>CS-14512</para></entry>
- <entry><para>The DeployVirtualMachine command will accept UUID for the “iptonetworklist” parameter.</para></entry>
- </row>
- <row>
- <entry><para>CS-14542</para></entry>
- <entry><para>Fixes issues with labeling networks for KVM.</para></entry>
- </row>
- <row>
- <entry><para>CS-14593</para></entry>
- <entry><para>Fixed an issue with where you hit a “EncryptionOperationNotPossibleException” when attempting to validate user credentials against a LDAP server.</para></entry>
- </row>
- <row>
- <entry><para>CS-14614</para></entry>
- <entry><para>Fixed issues with attempting to boot off of a CentOS 6.2 Live CD.</para></entry>
- </row>
- <row>
- <entry><para>CS-14622</para></entry>
- <entry><para>Fixed issues with dedicating public IP ranges to an account.</para></entry>
- </row>
- <row>
- <entry><para>CS-8222</para></entry>
- <entry><para>IP address usage records are now created for each day the IP address is assigned, in order to be consistent with virtual machine and storage usage records.</para></entry>
- </row>
- </tbody>
- </tgroup>
- </informaltable>
- </section>
- <section id="known-issues-3.0.2">
- <title>Known Issues in 3.0.2</title>
- <informaltable>
- <tgroup cols="2" align="left" colsep="1" rowsep="1">
- <colspec colwidth="1*" colname="1" colnum="1"/>
- <colspec colwidth="2*" colname="2" colnum="2"/>
- <thead>
- <row>
- <entry><para>Issue ID</para></entry>
- <entry><para>Description</para></entry>
- </row>
- </thead>
- <tbody>
- <row>
- <entry><para>CS-14103</para></entry>
- <entry><para>Global settings such as *.network.device (for example, xen.guest.network.device) are not cleared during upgrade from 2.2.x to 3.0.x. If you had manually set the global configuration parameter *.network.device (for example, xen.guest.network.device) to a custom network label, you will need to set the network traffic labels manually each time you set up a new zone after upgrade.</para></entry>
- </row>
- <row>
- <entry><para>CS-14201 (was 14430)</para></entry>
- <entry><para>VMWare: Template sizes are being reported different depending on whether the primary storage is using ISCSI or NFS.</para></entry>
- </row>
- <row>
- <entry><para>CS-14237 (was 14468)</para></entry>
- <entry><para>Primary Storage GC cannot occur when the first host in a given cluster is not in an “Up” state.</para></entry>
- </row>
- <row>
- <entry><para>CS-14275 (was 14506)</para></entry>
- <entry><para>F5: Unable to properly remove a F5 device.</para></entry>
- </row>
- <row>
- <entry><para>CS-14291 (was 14523)</para></entry>
- <entry><para>The EIP/ELB network offering for basic zones does not support multiple NetScalers.</para></entry>
- </row>
- <row>
- <entry><para>CS-14296 (was 14530)</para></entry>
- <entry><para>OVM: Network traffic labels are not supported.</para></entry>
- </row>
- <row>
- <entry><para>CS-14303 (was 14537)</para></entry>
- <entry><para>The IP addresses for a shared network are still being consumed even if no services are defined for that network.</para></entry>
- </row>
- <row>
- <entry><para>CS-14655</para></entry>
- <entry><para>XenServer known issue: If using network bonding on XenServer 6.0.x along with the CloudStack XenServer Support Package (CSP), interfaces, IPs, and networking can fail after adding hosts to the cloud and rebooting them. Workaround: patch each XenServer node, using the following steps. This patch is required only if using the CSP, and is a temporary requirement until XenServer issues the official hotfix for this issue. Before installing the CSP package, install the newer biosdevname rpm, selecting the correct patch for your version of XenServer: XenServer patch XS759 for XenServer 6.0.2 or XenServer patch XS753 for XenServer 6.0.0.</para>
- <orderedlist>
- <listitem><para>Download three files:</para>
- <itemizedlist>
- <listitem><para><ulink url="http://download.cloud.com/releases/3.0.2/60-net.rules.template">http://download.cloud.com/releases/3.0.2/60-net.rules.template</ulink></para></listitem>
- <listitem><para><ulink url="http://download.cloud.com/releases/3.0.2/net-rename-sideways.sh">http://download.cloud.com/releases/3.0.2/net-rename-sideways.sh</ulink></para></listitem>
- <listitem><para><ulink url="http://download.cloud.com/releases/3.0.2/biosdevname-0.3.7-1.xs753.i386.rpm">http://download.cloud.com/releases/3.0.2/biosdevname-0.3.7-1.xs753.i386.rpm</ulink> (for XenServer 6.0.0) or
- <ulink url="http://download.cloud.com/releases/3.0.2/biosdevname-0.3.7-1.xs759.i386.rpm">http://download.cloud.com/releases/3.0.2/biosdevname-0.3.7-1.xs759.i386.rpm</ulink> (for XenServer 6.0.2)</para></listitem>
- </itemizedlist></listitem>
- <listitem><para>Run the following. Substitute the filename of the patch you are using:</para><programlisting>rpm -ivh <packageName>.rpm -force</programlisting></listitem>
- <listitem><para>Replace /etc/udev/scripts/net-rename-sideways.sh with the new version.</para></listitem>
- <listitem><para>Replace /etc/sysconfig/network-scripts/interface-rename-data/60-net.rules.template with the newer version.</para></listitem>
- <listitem><para>Delete /etc/udev/rules.d/60-net.rules.</para></li
<TRUNCATED>