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/11 23:10:17 UTC
[9/11] docs: Fix indentation according to coding convention
http://git-wip-us.apache.org/repos/asf/incubator-cloudstack/blob/dcfa5a50/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
index 182ea40..3cef1d4 100644
--- a/docs/en-US/release-notes-3.0.4.xml
+++ b/docs/en-US/release-notes-3.0.4.xml
@@ -23,2413 +23,2413 @@
-->
<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
+ <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
+ <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 &
+ <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>
+ <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/acton/acton-systemvm-02062012.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
+ </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/acton/acton-systemvm-02062012.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
+ </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>
+ <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
+ </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
+ <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>
+ <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></l
<TRUNCATED>