From 296cf96fd92489f3be0256c0cac3145d14f0d82c Mon Sep 17 00:00:00 2001 From: Radhika PC Date: Fri, 19 Oct 2012 14:11:09 +0530 Subject: [PATCH] fix for 344 Signed-off-by: Radhika PC Conflicts: docs/en-US/release-notes.xml --- docs/en-US/citrix-xenserver-installation.xml | 1014 +++++++++++------ docs/en-US/host-add-xenserver-kvm-ovm.xml | 184 ++- .../management-server-install-systemvm.xml | 73 +- docs/en-US/prepare-system-vm-template.xml | 2 +- docs/en-US/release-notes.xml | 584 +++++++--- 5 files changed, 1202 insertions(+), 655 deletions(-) diff --git a/docs/en-US/citrix-xenserver-installation.xml b/docs/en-US/citrix-xenserver-installation.xml index c786b8347d4..867d36e1b10 100644 --- a/docs/en-US/citrix-xenserver-installation.xml +++ b/docs/en-US/citrix-xenserver-installation.xml @@ -1,5 +1,5 @@ - %BOOK_ENTITIES; ]> @@ -21,468 +21,728 @@ specific language governing permissions and limitations under the License. --> -
- Citrix XenServer Installation for &PRODUCT; - If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, follow the steps below. If you have previously installed XenServer and want to upgrade to another version, see . -
+ Citrix XenServer Installation for &PRODUCT; + If you want to use the Citrix XenServer hypervisor to run guest virtual machines, install + XenServer 6.0 or XenServer 6.0.2 on the host(s) in your cloud. For an initial installation, + follow the steps below. If you have previously installed XenServer and want to upgrade to + another version, see . +
System Requirements for XenServer Hosts - The host must be certified as compatible with one of the following. See the Citrix Hardware Compatibility Guide: http://hcl.xensource.com + + The host must be certified as compatible with one of the following. See the Citrix + Hardware Compatibility Guide: http://hcl.xensource.com - XenServer 5.6 SP2 - XenServer 6.0 - XenServer 6.0.2 + + XenServer 5.6 SP2 + + + XenServer 6.0 + + + XenServer 6.0.2 + - - You must re-install Citrix XenServer if you are going to re-use a host from a previous install.Must support HVM (Intel-VT or AMD-V enabled) - Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the release of hypervisor patches through your hypervisor vendor’s support channel, and apply patches as soon as possible after they are released. &PRODUCT; will not track or notify you of required hypervisor patches. It is essential that your hosts are completely up to date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to support any system that is not up to date with patches. - All hosts within a cluster must be homogenous. The CPUs must be of the same type, count, and feature flags. - Must support HVM (Intel-VT or AMD-V enabled in BIOS) - 64-bit x86 CPU (more cores results in better performance) - Hardware virtualization support required - 4 GB of memory - 36 GB of local disk - At least 1 NIC - Statically allocated IP Address - When you deploy &PRODUCT;, the hypervisor host must not have any VMs already running + + + You must re-install Citrix XenServer if you are going to re-use a host from a previous + install. + + + Must support HVM (Intel-VT or AMD-V enabled) + + + Be sure all the hotfixes provided by the hypervisor vendor are applied. Track the + release of hypervisor patches through your hypervisor vendor’s support channel, and apply + patches as soon as possible after they are released. &PRODUCT; will not track or notify + you of required hypervisor patches. It is essential that your hosts are completely up to + date with the provided hypervisor patches. The hypervisor vendor is likely to refuse to + support any system that is not up to date with patches. + + + All hosts within a cluster must be homogenous. The CPUs must be of the same type, + count, and feature flags. + + + Must support HVM (Intel-VT or AMD-V enabled in BIOS) + + + 64-bit x86 CPU (more cores results in better performance) + + + Hardware virtualization support required + + + 4 GB of memory + + + 36 GB of local disk + + + At least 1 NIC + + + Statically allocated IP Address + + + When you deploy &PRODUCT;, the hypervisor host must not have any VMs already + running + - The lack of up-do-date hotfixes can lead to data corruption and lost VMs. -
-
+ + The lack of up-do-date hotfixes can lead to data corruption and lost VMs. + +
+
XenServer Installation Steps - From https://www.citrix.com/English/ss/downloads/, download the appropriate version of XenServer for your &PRODUCT; version (see ). Install it using the Citrix XenServer Installation Guide. - After installation, perform the following configuration steps, which are described in the next few sections: - - - - - - - Required - Optional - - - - - - - - - - Set up SR if not using NFS, iSCSI, or local disk; see - - - - - - - - - - - - - + + From https://www.citrix.com/English/ss/downloads/, download the appropriate version + of XenServer for your &PRODUCT; version (see ). Install it using the Citrix XenServer + Installation Guide. + + + After installation, perform the following configuration steps, which are described in + the next few sections: + + + + + + + Required + Optional + + + + + + + + + + Set up SR if not using NFS, iSCSI, or local disk; see + + + + + + + + + + + + + -
-
+
+
Configure XenServer dom0 Memory - Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, but the same information applies to XenServer 6.0. -
-
+ Configure the XenServer dom0 settings to allocate more memory to dom0. This can enable + XenServer to handle larger numbers of virtual machines. We recommend 2940 MB of RAM for + XenServer dom0. For instructions on how to do this, see http://support.citrix.com/article/CTX126531. The article refers to XenServer 5.6, + but the same information applies to XenServer 6.0. +
+
Username and Password - All XenServers in a cluster must have the same username and password as configured in &PRODUCT;. -
-
+ All XenServers in a cluster must have the same username and password as configured in + &PRODUCT;. +
+
Time Synchronization The host must be set to use NTP. All hosts in a pod must have the same time. - - Install NTP. - # yum install ntp - - - Edit the NTP configuration file to point to your NTP server. - # vi /etc/ntp.conf - Add one or more server lines in this file with the names of the NTP servers you want to use. For example: - server 0.xenserver.pool.ntp.org + + Install NTP. + # yum install ntp + + + Edit the NTP configuration file to point to your NTP server. + # vi /etc/ntp.conf + Add one or more server lines in this file with the names of the NTP servers you want + to use. For example: + server 0.xenserver.pool.ntp.org server 1.xenserver.pool.ntp.org server 2.xenserver.pool.ntp.org server 3.xenserver.pool.ntp.org - - - Restart the NTP client. - # service ntpd restart - - - Make sure NTP will start again upon reboot. - # chkconfig ntpd on - + + + Restart the NTP client. + # service ntpd restart + + + Make sure NTP will start again upon reboot. + # chkconfig ntpd on + -
-
+
+
Licensing - Citrix XenServer Free version provides 30 days usage without a license. Following the 30 day trial, XenServer requires a free activation and license. You can choose to install a license now or skip this step. If you skip this step, you will need to install a license when you activate and license the XenServer. + Citrix XenServer Free version provides 30 days usage without a license. Following the 30 + day trial, XenServer requires a free activation and license. You can choose to install a + license now or skip this step. If you skip this step, you will need to install a license when + you activate and license the XenServer.
- Getting and Deploying a License - If you choose to install a license now you will need to use the XenCenter to activate and get a license. - - In XenCenter, click Tools > License manager. - Select your XenServer and select Activate Free XenServer. - Request a license. - - You can install the license with XenCenter or using the xe command line tool. + Getting and Deploying a License + If you choose to install a license now you will need to use the XenCenter to activate + and get a license. + + + In XenCenter, click Tools > License manager. + + + Select your XenServer and select Activate Free XenServer. + + + Request a license. + + + You can install the license with XenCenter or using the xe command line tool.
-
-
+
+
Install &PRODUCT; XenServer Support Package (CSP) (Optional) - To enable security groups, elastic load balancing, and elastic IP on XenServer, download and install the &PRODUCT; XenServer Support Package (CSP). After installing XenServer, perform the following additional steps on each XenServer host. + To enable security groups, elastic load balancing, and elastic IP on XenServer, download + and install the &PRODUCT; XenServer Support Package (CSP). After installing XenServer, perform + the following additional steps on each XenServer host. - - Download the CSP software onto the XenServer host from one of the following links: - For XenServer 6.0.2: - http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz - For XenServer 5.6 SP2: - http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz - For XenServer 6.0: - http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz - - - Extract the file: - # tar xf xenserver-cloud-supp.tgz - - - Run the following script: - # xe-install-supplemental-pack xenserver-cloud-supp.iso - - - If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS): - # xe-switch-network-backend bridge - Restart the host machine when prompted. - + + Download the CSP software onto the XenServer host from one of the following + links: + For XenServer 6.0.2: + http://download.cloud.com/releases/3.0.1/XS-6.0.2/xenserver-cloud-supp.tgz + For XenServer 5.6 SP2: + http://download.cloud.com/releases/2.2.0/xenserver-cloud-supp.tgz + For XenServer 6.0: + http://download.cloud.com/releases/3.0/xenserver-cloud-supp.tgz + + + Extract the file: + # tar xf xenserver-cloud-supp.tgz + + + Run the following script: + # xe-install-supplemental-pack xenserver-cloud-supp.iso + + + If the XenServer host is part of a zone that uses basic networking, disable Open + vSwitch (OVS): + # xe-switch-network-backend bridge + Restart the host machine when prompted. + The XenServer host is now ready to be added to &PRODUCT;. -
-
+
+
Primary Storage Setup for XenServer - &PRODUCT; natively supports NFS, iSCSI and local storage. If you are using one of these storage types, there is no need to create the XenServer Storage Repository ("SR"). - If, however, you would like to use storage connected via some other technology, such as FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you have your hosts in a XenServer pool, perform the steps on the master node. If you are working with a single XenServer which is not part of a cluster, perform the steps on that XenServer. + &PRODUCT; natively supports NFS, iSCSI and local storage. If you are using one of these + storage types, there is no need to create the XenServer Storage Repository ("SR"). + If, however, you would like to use storage connected via some other technology, such as + FiberChannel, you must set up the SR yourself. To do so, perform the following steps. If you + have your hosts in a XenServer pool, perform the steps on the master node. If you are working + with a single XenServer which is not part of a cluster, perform the steps on that + XenServer. - Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage host. - - Rescan the SCSI bus. Either use the following command or use XenCenter to perform an HBA rescan. - # scsi-rescan - - Repeat step 2 on every host. - - Check to be sure you see the new SCSI disk. - # ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l - The output should look like this, although the specific file name will be different (scsi-<scsiID>): - lrwxrwxrwx 1 root root 9 Mar 16 13:47 + + Connect FiberChannel cable to all hosts in the cluster and to the FiberChannel storage + host. + + + Rescan the SCSI bus. Either use the following command or use XenCenter to perform an + HBA rescan. + # scsi-rescan + + + Repeat step 2 on every host. + + + Check to be sure you see the new SCSI disk. + # ls /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -l + The output should look like this, although the specific file name will be different + (scsi-<scsiID>): + lrwxrwxrwx 1 root root 9 Mar 16 13:47 /dev/disk/by-id/scsi-360a98000503365344e6f6177615a516b -> ../../sdc - - Repeat step 4 on every host. - - On the storage server, run this command to get a unique ID for the new SR. - # uuidgen - The output should look like this, although the specific ID will be different: - e6849e96-86c3-4f2c-8fcc-350cc711be3d - - - Create the FiberChannel SR. In name-label, use the unique ID you just generated. - + + + Repeat step 4 on every host. + + + On the storage server, run this command to get a unique ID for the new SR. + # uuidgen + The output should look like this, although the specific ID will be different: + e6849e96-86c3-4f2c-8fcc-350cc711be3d + + + Create the FiberChannel SR. In name-label, use the unique ID you just + generated. + # xe sr-create type=lvmohba shared=true device-config:SCSIid=360a98000503365344e6f6177615a516b name-label="e6849e96-86c3-4f2c-8fcc-350cc711be3d" - This command returns a unique ID for the SR, like the following example (your ID will be different): - 7a143820-e893-6c6a-236e-472da6ee66bf + This command returns a unique ID for the SR, like the following example (your ID will + be different): + 7a143820-e893-6c6a-236e-472da6ee66bf - To create a human-readable description for the SR, use the following command. In uuid, use the SR ID returned by the previous command. In name-description, set whatever friendly text you prefer. - # xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage repository" - Make note of the values you will need when you add this storage to &PRODUCT; later (see ). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d). + To create a human-readable description for the SR, use the following command. In uuid, + use the SR ID returned by the previous command. In name-description, set whatever friendly + text you prefer. + # xe sr-param-set uuid=7a143820-e893-6c6a-236e-472da6ee66bf name-description="Fiber Channel storage repository" + Make note of the values you will need when you add this storage to &PRODUCT; later + (see ). In the Add Primary Storage dialog, in + Protocol, you will choose PreSetup. In SR Name-Label, you will enter the name-label you + set earlier (in this example, e6849e96-86c3-4f2c-8fcc-350cc711be3d). - (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the documentation provided by the SAN vendor. - -
-
- iSCSI Multipath Setup for XenServer (Optional) - When setting up the storage repository on a Citrix XenServer, you can enable multipath I/O, which uses redundant physical components to provide greater reliability in the connection between the server and the SAN. To enable multipathing, use a SAN solution that is supported for Citrix servers and follow the procedures in Citrix documentation. The following links provide a starting point: - - http://support.citrix.com/article/CTX118791 - http://support.citrix.com/article/CTX125403 - - You can also ask your SAN vendor for advice about setting up your Citrix repository for multipathing. - Make note of the values you will need when you add this storage to the &PRODUCT; later (see ). In the Add Primary Storage dialog, in Protocol, you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the SR. - If you encounter difficulty, address the support team for the SAN provided by your vendor. If they are not able to solve your issue, see Contacting Support. -
-
- Physical Networking Setup for XenServer - Once XenServer has been installed, you may need to do some additional network configuration. At this point in the installation, you should have a plan for what NICs the host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to implement your plan. - If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then eth0 must be in the private bond on all hosts in the cluster. - The IP address assigned for the management network interface must be static. It can be set on the host itself or obtained via static DHCP. - &PRODUCT; configures network traffic of various types to use different NICs or bonds on the XenServer host. You can control this process and provide input to the Management Server through the use of XenServer network name labels. The name labels are placed on physical interfaces or bonds and configured in &PRODUCT;. In some simple cases the name labels are not required. -
- Configuring Public Network with a Dedicated NIC for XenServer (Optional) - &PRODUCT; supports the use of a second NIC (or bonded pair of NICs, described in ) for the public network. If bonding is not used, the public network can be on any NIC and can be on different NICs on the hosts in a cluster. For example, the public network can be on eth0 on node A and eth1 on node B. However, the XenServer name-label for the public network must be identical across all hosts. The following examples set the network label to "cloud-public". After the management server is installed and running you must configure it with the name of the chosen network label (e.g. "cloud-public"); this is discussed in . - If you are using two NICs bonded together to create a public network, see . - If you are using a single dedicated NIC to provide public network access, follow this procedure on each new host that is added to &PRODUCT; before adding the host. - - Run xe network-list and find the public network. This is usually attached to the NIC that is public. Once you find the network make note of its UUID. Call this <UUID-Public>. - - Run the following command. - # xe network-param-set name-label=cloud-public uuid=<UUID-Public> - - + + (Optional) If you want to enable multipath I/O on a FiberChannel SAN, refer to the + documentation provided by the SAN vendor. + +
-
+
+ iSCSI Multipath Setup for XenServer (Optional) + When setting up the storage repository on a Citrix XenServer, you can enable multipath + I/O, which uses redundant physical components to provide greater reliability in the connection + between the server and the SAN. To enable multipathing, use a SAN solution that is supported + for Citrix servers and follow the procedures in Citrix documentation. The following links + provide a starting point: + + + http://support.citrix.com/article/CTX118791 + + + http://support.citrix.com/article/CTX125403 + + + You can also ask your SAN vendor for advice about setting up your Citrix repository for + multipathing. + Make note of the values you will need when you add this storage to the &PRODUCT; later + (see ). In the Add Primary Storage dialog, in Protocol, + you will choose PreSetup. In SR Name-Label, you will enter the same name used to create the + SR. + If you encounter difficulty, address the support team for the SAN provided by your vendor. + If they are not able to solve your issue, see Contacting Support. +
+
+ Physical Networking Setup for XenServer + Once XenServer has been installed, you may need to do some additional network + configuration. At this point in the installation, you should have a plan for what NICs the + host will have and what traffic each NIC will carry. The NICs should be cabled as necessary to + implement your plan. + If you plan on using NIC bonding, the NICs on all hosts in the cluster must be cabled + exactly the same. For example, if eth0 is in the private bond on one host in a cluster, then + eth0 must be in the private bond on all hosts in the cluster. + The IP address assigned for the management network interface must be static. It can be set + on the host itself or obtained via static DHCP. + &PRODUCT; configures network traffic of various types to use different NICs or bonds on + the XenServer host. You can control this process and provide input to the Management Server + through the use of XenServer network name labels. The name labels are placed on physical + interfaces or bonds and configured in &PRODUCT;. In some simple cases the name labels are not + required. +
+ Configuring Public Network with a Dedicated NIC for XenServer (Optional) + &PRODUCT; supports the use of a second NIC (or bonded pair of NICs, described in ) for the public network. If bonding is not used, the + public network can be on any NIC and can be on different NICs on the hosts in a cluster. For + example, the public network can be on eth0 on node A and eth1 on node B. However, the + XenServer name-label for the public network must be identical across all hosts. The + following examples set the network label to "cloud-public". After the management + server is installed and running you must configure it with the name of the chosen network + label (e.g. "cloud-public"); this is discussed in . + If you are using two NICs bonded together to create a public network, see . + If you are using a single dedicated NIC to provide public network access, follow this + procedure on each new host that is added to &PRODUCT; before adding the host. + + + Run xe network-list and find the public network. This is usually attached to the NIC + that is public. Once you find the network make note of its UUID. Call this + <UUID-Public>. + + + Run the following command. + # xe network-param-set name-label=cloud-public uuid=<UUID-Public> + + +
+
Configuring Multiple Guest Networks for XenServer (Optional) - &PRODUCT; supports the use of multiple guest networks with the XenServer hypervisor. Each network is assigned a name-label in XenServer. For example, you might have two networks with the labels "cloud-guest" and "cloud-guest2". After the management server is installed and running, you must add the networks and use these labels so that &PRODUCT; is aware of the networks. + &PRODUCT; supports the use of multiple guest networks with the XenServer hypervisor. + Each network is assigned a name-label in XenServer. For example, you might have two networks + with the labels "cloud-guest" and "cloud-guest2". After the management + server is installed and running, you must add the networks and use these labels so that + &PRODUCT; is aware of the networks. Follow this procedure on each new host before adding the host to &PRODUCT;: - Run xe network-list and find one of the guest networks. Once you find the network make note of its UUID. Call this <UUID-Guest>. - - Run the following command, substituting your own name-label and uuid values. - # xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest> - - Repeat these steps for each additional guest network, using a different name-label and uuid each time. + + Run xe network-list and find one of the guest networks. Once you find the network + make note of its UUID. Call this <UUID-Guest>. + + + Run the following command, substituting your own name-label and uuid values. + # xe network-param-set name-label=<cloud-guestN> uuid=<UUID-Guest> + + + Repeat these steps for each additional guest network, using a different name-label + and uuid each time. + -
-
+
+
Separate Storage Network for XenServer (Optional) - You can optionally set up a separate storage network. This should be done first on the host, before implementing the bonding steps below. This can be done using one or two available NICs. With two NICs bonding may be done as above. It is the administrator's responsibility to set up a separate storage network. - Give the storage network a different name-label than what will be given for other networks. - For the separate storage network to work correctly, it must be the only interface that can ping the primary storage device's IP address. For example, if eth0 is the management network NIC, ping -I eth0 <primary storage device IP> must fail. In all deployments, secondary storage devices must be pingable from the management network NIC or bond. If a secondary storage device has been placed on the storage network, it must also be pingable via the storage network NIC or bond on the hosts as well. - You can set up two separate storage networks as well. For example, if you intend to implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two networks needs a unique name-label. - If no bonding is done, the administrator must set up and name-label the separate storage network on all hosts (masters and slaves). + You can optionally set up a separate storage network. This should be done first on the + host, before implementing the bonding steps below. This can be done using one or two + available NICs. With two NICs bonding may be done as above. It is the administrator's + responsibility to set up a separate storage network. + Give the storage network a different name-label than what will be given for other + networks. + For the separate storage network to work correctly, it must be the only interface that + can ping the primary storage device's IP address. For example, if eth0 is the + management network NIC, ping -I eth0 <primary storage device IP> must fail. In all + deployments, secondary storage devices must be pingable from the management network NIC or + bond. If a secondary storage device has been placed on the storage network, it must also be + pingable via the storage network NIC or bond on the hosts as well. + You can set up two separate storage networks as well. For example, if you intend to + implement iSCSI multipath, dedicate two non-bonded NICs to multipath. Each of the two + networks needs a unique name-label. + If no bonding is done, the administrator must set up and name-label the separate storage + network on all hosts (masters and slaves). Here is an example to set up eth5 to access a storage network on 172.16.0.0/24. # xe pif-list host-name-label='hostname' device=eth5 -uuid ( RO) : ab0d3dd4-5744-8fae-9693-a022c7a3471d - device ( RO): eth5 +uuid(RO): ab0d3dd4-5744-8fae-9693-a022c7a3471d +device ( RO): eth5 #xe pif-reconfigure-ip DNS=172.16.3.3 gateway=172.16.0.1 IP=172.16.0.55 mode=static netmask=255.255.255.0 uuid=ab0d3dd4-5744-8fae-9693-a022c7a3471d -
-
+
+
NIC Bonding for XenServer (Optional) - XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded together to carry public, private, and guest traffic, or some combination of these. Separate storage networks are also possible. Here are some example supported configurations: + XenServer supports Source Level Balancing (SLB) NIC bonding. Two NICs can be bonded + together to carry public, private, and guest traffic, or some combination of these. Separate + storage networks are also possible. Here are some example supported configurations: - 2 NICs on private, 2 NICs on public, 2 NICs on storage - 2 NICs on private, 1 NIC on public, storage uses management network - 2 NICs on private, 2 NICs on public, storage uses management network - 1 NIC for private, public, and storage + + 2 NICs on private, 2 NICs on public, 2 NICs on storage + + + 2 NICs on private, 1 NIC on public, storage uses management network + + + 2 NICs on private, 2 NICs on public, storage uses management network + + + 1 NIC for private, public, and storage + All NIC bonding is optional. - XenServer expects all nodes in a cluster will have the same network cabling and same bonds implemented. In an installation the master will be the first host that was added to the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds present on the master set the expectation for hosts added to the cluster later. The procedure to set up bonds on the master and slaves are different, and are described below. There are several important implications of this: + XenServer expects all nodes in a cluster will have the same network cabling and same + bonds implemented. In an installation the master will be the first host that was added to + the cluster and the slave hosts will be all subsequent hosts added to the cluster. The bonds + present on the master set the expectation for hosts added to the cluster later. The + procedure to set up bonds on the master and slaves are different, and are described below. + There are several important implications of this: - You must set bonds on the first host added to a cluster. Then you must use xe commands as below to establish the same bonds in the second and subsequent hosts added to a cluster. - Slave hosts in a cluster must be cabled exactly the same as the master. For example, if eth0 is in the private bond on the master, it must be in the management network for added slave hosts. + + You must set bonds on the first host added to a cluster. Then you must use xe + commands as below to establish the same bonds in the second and subsequent hosts added + to a cluster. + + + Slave hosts in a cluster must be cabled exactly the same as the master. For example, + if eth0 is in the private bond on the master, it must be in the management network for + added slave hosts. +
- Management Network Bonding - The administrator must bond the management network NICs prior to adding the host to &PRODUCT;. + Management Network Bonding + The administrator must bond the management network NICs prior to adding the host to + &PRODUCT;.
- Creating a Private Bond on the First Host in the Cluster - Use the following steps to create a bond in XenServer. These steps should be run on only the first host in a cluster. This example creates the cloud-private network with two physical NICs (eth0 and eth1) bonded into it. - - - Find the physical NICs that you want to bond together. - -# xe pif-list host-name-label='hostname' device=eth0 + Creating a Private Bond on the First Host in the Cluster + Use the following steps to create a bond in XenServer. These steps should be run on + only the first host in a cluster. This example creates the cloud-private network with two + physical NICs (eth0 and eth1) bonded into it. + + + Find the physical NICs that you want to bond together. + # xe pif-list host-name-label='hostname' device=eth0 # xe pif-list host-name-label='hostname' device=eth1 - These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID. - - - Create a new network for the bond. For example, a new network with name "cloud-private". - This label is important. &PRODUCT; looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the management network. - -# xe network-create name-label=cloud-private + These command shows the eth0 and eth1 NICs and their UUIDs. Substitute the ethX + devices of your choice. Call the UUID's returned by the above command slave1-UUID + and slave2-UUID. + + + Create a new network for the bond. For example, a new network with name + "cloud-private". + This label is important. &PRODUCT; looks for a network by a + name you configure. You must use the same name-label for all hosts in the cloud for + the management network. + # xe network-create name-label=cloud-private # xe bond-create network-uuid=[uuid of cloud-private created above] pif-uuids=[slave1-uuid],[slave2-uuid] - - - Now you have a bonded pair that can be recognized by &PRODUCT; as the management network. + + + Now you have a bonded pair that can be recognized by &PRODUCT; as the management + network.
- Public Network Bonding - Bonding can be implemented on a separate, public network. The administrator is responsible for creating a bond for the public network if that network will be bonded and will be separate from the management network. + Public Network Bonding + Bonding can be implemented on a separate, public network. The administrator is + responsible for creating a bond for the public network if that network will be bonded and + will be separate from the management network.
- Creating a Public Bond on the First Host in the Cluster - These steps should be run on only the first host in a cluster. This example creates the cloud-public network with two physical NICs (eth2 and eth3) bonded into it. - - - Find the physical NICs that you want to bond together. - -#xe pif-list host-name-label='hostname' device=eth2 + Creating a Public Bond on the First Host in the Cluster + These steps should be run on only the first host in a cluster. This example creates + the cloud-public network with two physical NICs (eth2 and eth3) bonded into it. + + + Find the physical NICs that you want to bond together. + #xe pif-list host-name-label='hostname' device=eth2 # xe pif-list host-name-label='hostname' device=eth3 - These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX devices of your choice. Call the UUID's returned by the above command slave1-UUID and slave2-UUID. - - - Create a new network for the bond. For example, a new network with name "cloud-public". - This label is important. &PRODUCT; looks for a network by a name you configure. You must use the same name-label for all hosts in the cloud for the public network. - -# xe network-create name-label=cloud-public + These command shows the eth2 and eth3 NICs and their UUIDs. Substitute the ethX + devices of your choice. Call the UUID's returned by the above command slave1-UUID + and slave2-UUID. + + + Create a new network for the bond. For example, a new network with name + "cloud-public". + This label is important. &PRODUCT; looks for a network by a + name you configure. You must use the same name-label for all hosts in the cloud for + the public network. + # xe network-create name-label=cloud-public # xe bond-create network-uuid=[uuid of cloud-public created above] pif-uuids=[slave1-uuid],[slave2-uuid] - - - Now you have a bonded pair that can be recognized by &PRODUCT; as the public network. + + + Now you have a bonded pair that can be recognized by &PRODUCT; as the public + network.
- Adding More Hosts to the Cluster - With the bonds (if any) established on the master, you should add additional, slave hosts. Run the following command for all additional hosts to be added to the cluster. This will cause the host to join the master in a single XenServer pool. - -# xe pool-join master-address=[master IP] master-username=root + Adding More Hosts to the Cluster + With the bonds (if any) established on the master, you should add additional, slave + hosts. Run the following command for all additional hosts to be added to the cluster. This + will cause the host to join the master in a single XenServer pool. + # xe pool-join master-address=[master IP] master-username=root master-password=[your password]
- Complete the Bonding Setup Across the Cluster - With all hosts added to the pool, run the cloud-setup-bond script. This script will complete the configuration and set up of the bonds across all hosts in the cluster. - - Copy the script from the Management Server in /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable. - - Run the script: - # ./cloud-setup-bonding.sh - - - Now the bonds are set up and configured properly across the cluster. + Complete the Bonding Setup Across the Cluster + With all hosts added to the pool, run the cloud-setup-bond script. This script will + complete the configuration and set up of the bonds across all hosts in the cluster. + + + Copy the script from the Management Server in + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the + master host and ensure it is executable. + + + Run the script: + # ./cloud-setup-bonding.sh + + + Now the bonds are set up and configured properly across the cluster.
-
-
- Upgrading XenServer Versions - This section tells how to upgrade XenServer software on &PRODUCT; hosts. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade. - Be sure the hardware is certified compatible with the new version of XenServer. - To upgrade XenServer: - +
+
+ Upgrading XenServer Versions + This section tells how to upgrade XenServer software on &PRODUCT; hosts. The actual + upgrade is described in XenServer documentation, but there are some additional steps you must + perform before and after the upgrade. + + Be sure the hardware is certified compatible with the new version of XenServer. + + To upgrade XenServer: + - Upgrade the database. On the Management Server node: - - - Back up the database: - -# mysqldump --user=root --databases cloud > cloud.backup.sql + Upgrade the database. On the Management Server node: + + + Back up the database: + # mysqldump --user=root --databases cloud > cloud.backup.sql # mysqldump --user=root --databases cloud_usage > cloud_usage.backup.sql - - - You might need to change the OS type settings for VMs running on the upgraded hosts. - - If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit). - If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). Change any VMs that have the 64-bit versions of these same OS types to Other Linux (64-bit). - If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the above. - - - - Restart the Management Server and Usage Server. You only need to do this once for all clusters. - -# service cloud-management start + + + You might need to change the OS type settings for VMs running on the upgraded + hosts. + + + If you upgraded from XenServer 5.6 GA to XenServer 5.6 SP2, change any VMs + that have the OS type CentOS 5.5 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), + or Red Hat Enterprise Linux 5.5 (32-bit) to Other Linux (32-bit). Change any VMs + that have the 64-bit versions of these same OS types to Other Linux + (64-bit). + + + If you upgraded from XenServer 5.6 SP2 to XenServer 6.0.2, change any VMs that + have the OS type CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux + 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.6 + (32-bit) , or Red Hat Enterprise Linux 5.7 (32-bit) to Other Linux (32-bit). + Change any VMs that have the 64-bit versions of these same OS types to Other Linux + (64-bit). + + + If you upgraded from XenServer 5.6 to XenServer 6.0.2, do all of the + above. + + + + + Restart the Management Server and Usage Server. You only need to do this once for + all clusters. + # service cloud-management start # service cloud-usage start - - + + - Disconnect the XenServer cluster from &PRODUCT;. - - Log in to the &PRODUCT; UI as root. - Navigate to the XenServer cluster, and click Actions – Unmanage. - Watch the cluster status until it shows Unmanaged. - + Disconnect the XenServer cluster from &PRODUCT;. + + + Log in to the &PRODUCT; UI as root. + + + Navigate to the XenServer cluster, and click Actions – Unmanage. + + + Watch the cluster status until it shows Unmanaged. + + - Log in to one of the hosts in the cluster, and run this command to clean up the VLAN: - # . /opt/xensource/bin/cloud-clean-vlan.sh + Log in to one of the hosts in the cluster, and run this command to clean up the + VLAN: + # . /opt/xensource/bin/cloud-clean-vlan.sh - Still logged in to the host, run the upgrade preparation script: - # /opt/xensource/bin/cloud-prepare-upgrade.sh - Troubleshooting: If you see the error "can't eject CD," log in to the VM and umount the CD, then run the script again. + Still logged in to the host, run the upgrade preparation script: + # /opt/xensource/bin/cloud-prepare-upgrade.sh + Troubleshooting: If you see the error "can't eject CD," log in to the + VM and umount the CD, then run the script again. - Upgrade the XenServer software on all hosts in the cluster. Upgrade the master first. - - - Live migrate all VMs on this host to other hosts. See the instructions for live migration in the Administrator's Guide. - Troubleshooting: You might see the following error when you migrate a VM: - -[root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM + Upgrade the XenServer software on all hosts in the cluster. Upgrade the master + first. + + + Live migrate all VMs on this host to other hosts. See the instructions for live + migration in the Administrator's Guide. + Troubleshooting: You might see the following error when you migrate a VM: + [root@xenserver-qa-2-49-4 ~]# xe vm-migrate live=true host=xenserver-qa-2-49-5 vm=i-2-8-VM You attempted an operation on a VM which requires PV drivers to be installed but the drivers were not detected. vm: b6cf79c8-02ee-050b-922f-49583d9f1a14 (i-2-8-VM) - To solve this issue, run the following: - # /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14 - - Reboot the host. - Upgrade to the newer version of XenServer. Use the steps in XenServer documentation. - - After the upgrade is complete, copy the following files from the management server to this host, in the directory locations shown below: - - - - - - - Copy this Management Server file... - ...to this location on the XenServer host - - - - - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py - /opt/xensource/sm/NFSSR.py - - - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/setupxenserver.sh - /opt/xensource/bin/setupxenserver.sh - - - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/make_migratable.sh - /opt/xensource/bin/make_migratable.sh - - - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/cloud-clean-vlan.sh - /opt/xensource/bin/cloud-clean-vlan.sh - - - - - - - Run the following script: - # /opt/xensource/bin/setupxenserver.sh - Troubleshooting: If you see the following error message, you can safely ignore it. - mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory - - - Plug in the storage repositories (physical block devices) to the XenServer host: - # for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done - Note: If you add a host to this XenServer pool, you need to migrate all VMs on this host to other hosts, and eject this host from XenServer pool. - + To solve this issue, run the following: + # /opt/xensource/bin/make_migratable.sh b6cf79c8-02ee-050b-922f-49583d9f1a14 + + + Reboot the host. + + + Upgrade to the newer version of XenServer. Use the steps in XenServer + documentation. + + + After the upgrade is complete, copy the following files from the management server + to this host, in the directory locations shown below: + + + + + + + Copy this Management Server file... + ...to this location on the XenServer host + + + + + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py + /opt/xensource/sm/NFSSR.py + + + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh + /opt/xensource/bin/setupxenserver.sh + + + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh + /opt/xensource/bin/make_migratable.sh + + + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-clean-vlan.sh + /opt/xensource/bin/cloud-clean-vlan.sh + + + + + + + Run the following script: + # /opt/xensource/bin/setupxenserver.sh + Troubleshooting: If you see the following error message, you can safely ignore + it. + mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory + + + Plug in the storage repositories (physical block devices) to the XenServer + host: + # for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; done + Note: If you add a host to this XenServer pool, you need to migrate all VMs on + this host to other hosts, and eject this host from XenServer pool. + + + + + Repeat these steps to upgrade every host in the cluster to the same version of + XenServer. + + + Run the following command on one host in the XenServer cluster to clean up the host + tags: + # for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done; + + When copying and pasting a command, be sure the command has pasted as a single line + before executing. Some document viewers may introduce unwanted line breaks in copied + text. + + + + Reconnect the XenServer cluster to &PRODUCT;. + + + Log in to the &PRODUCT; UI as root. + + + Navigate to the XenServer cluster, and click Actions – Manage. + + + Watch the status to see that all the hosts come up. + + + + + After all hosts are up, run the following on one host in the cluster: + # /opt/xensource/bin/cloud-clean-vlan.sh + - - Repeat these steps to upgrade every host in the cluster to the same version of XenServer. - - Run the following command on one host in the XenServer cluster to clean up the host tags: - # for host in $(xe host-list | grep ^uuid | awk '{print $NF}') ; do xe host-param-clear uuid=$host param-name=tags; done; - When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text. - - - Reconnect the XenServer cluster to &PRODUCT;. - - Log in to the &PRODUCT; UI as root. - Navigate to the XenServer cluster, and click Actions – Manage. - Watch the status to see that all the hosts come up. - - - - After all hosts are up, run the following on one host in the cluster: - # /opt/xensource/bin/cloud-clean-vlan.sh - - -
+
diff --git a/docs/en-US/host-add-xenserver-kvm-ovm.xml b/docs/en-US/host-add-xenserver-kvm-ovm.xml index 710133211cb..855177abd24 100644 --- a/docs/en-US/host-add-xenserver-kvm-ovm.xml +++ b/docs/en-US/host-add-xenserver-kvm-ovm.xml @@ -21,68 +21,132 @@ specific language governing permissions and limitations under the License. --> -
- Adding a Host (XenServer, KVM, or OVM) - XenServer, KVM, and Oracle VM (OVM) hosts can be added to a cluster at any time. + Adding a Host (XenServer, KVM, or OVM) + XenServer, KVM, and Oracle VM (OVM) hosts can be added to a cluster at any time. +
+ Requirements for XenServer, KVM, and OVM Hosts + + Make sure the hypervisor host does not have any VMs already running before you add it to + &PRODUCT;. + + Configuration requirements: + + + Each cluster must contain only hosts with the identical hypervisor. + + + For XenServer, do not put more than 8 hosts in a cluster. + + + For KVM, do not put more than 16 hosts in a cluster. + + + For hardware requirements, see the installation section for your hypervisor in the + &PRODUCT; Installation Guide.
- Requirements for XenServer, KVM, and OVM Hosts - Make sure the hypervisor host does not have any VMs already running before you add it to &PRODUCT;. - Configuration requirements: + XenServer Host Additional Requirements + If network bonding is in use, the administrator must cable the new host identically to + other hosts in the cluster. + For all additional hosts to be added to the cluster, run the following command. This + will cause the host to join the master in a XenServer pool. + # xe pool-join master-address=[master IP] master-username=root master-password=[your password] + + When copying and pasting a command, be sure the command has pasted as a single line + before executing. Some document viewers may introduce unwanted line breaks in copied + text. + + With all hosts added to the XenServer pool, run the cloud-setup-bond script. This script + will complete the configuration and setup of the bonds on the new hosts in the + cluster. + + + Copy the script from the Management Server in + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the + master host and ensure it is executable. + + + Run the script: + # ./cloud-setup-bonding.sh + + +
+
+ KVM Host Additional Requirements + + + If shared mountpoint storage is in use, the administrator should ensure that the new + host has all the same mountpoints (with storage mounted) as the other hosts in the + cluster. + + + Make sure the new host has the same network configuration (guest, private, and + public network) as other hosts in the cluster. + + +
+
+ OVM Host Additional Requirements + Before adding a used host in &PRODUCT;, as part of the cleanup procedure on the host, be + sure to remove /etc/ovs-agent/db/. +
+
+
+ Adding a XenServer, KVM, or OVM Host + + + If you have not already done so, install the hypervisor software on the host. You will + need to know which version of the hypervisor software version is supported by &PRODUCT; + and what additional configuration is required to ensure the host will work with &PRODUCT;. + To find these installation details, see the appropriate section for your hypervisor in the + &PRODUCT; Installation Guide. + + + Log in to the &PRODUCT; UI as administrator. + + + In the left navigation, choose Infrastructure. In Zones, click View More, then click + the zone in which you want to add the host. + + + Click the Compute tab. In the Clusters node, click View All. + + + Click the cluster where you want to add the host. + + + Click View Hosts. + + + Click Add Host. + + + Provide the following information. - Each cluster must contain only hosts with the identical hypervisor. - For XenServer, do not put more than 8 hosts in a cluster. - For KVM, do not put more than 16 hosts in a cluster. + + Host Name. The DNS name or IP address of the host. + + + Username. Usually root. + + + Password. This is the password for the user named above (from your XenServer, KVM, + or OVM install). + + + Host Tags (Optional). Any labels that you use to categorize hosts for ease of + maintenance. For example, you can set to the cloud's HA tag (set in the ha.tag global + configuration parameter) if you want this host to be used only for VMs with the "high + availability" feature enabled. For more information, see HA-Enabled Virtual Machines + as well as HA for Hosts. + - For hardware requirements, see the installation section for your hypervisor in the &PRODUCT; Installation Guide. -
- XenServer Host Additional Requirements - If network bonding is in use, the administrator must cable the new host identically to other hosts in the cluster. - For all additional hosts to be added to the cluster, run the following command. This will cause the host to join the master in a XenServer pool. - # xe pool-join master-address=[master IP] master-username=root master-password=[your password] - When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text. - With all hosts added to the XenServer pool, run the cloud-setup-bond script. This script will complete the configuration and setup of the bonds on the new hosts in the cluster. - - Copy the script from the Management Server in /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable. - Run the script: - # ./cloud-setup-bonding.sh - - -
-
- KVM Host Additional Requirements - - If shared mountpoint storage is in use, the administrator should ensure that the new host has all the same mountpoints (with storage mounted) as the other hosts in the cluster. - Make sure the new host has the same network configuration (guest, private, and public network) as other hosts in the cluster. - -
-
- OVM Host Additional Requirements - Before adding a used host in &PRODUCT;, as part of the cleanup procedure on the host, be sure to remove - /etc/ovs-agent/db/. - -
-
-
- Adding a XenServer, KVM, or OVM Host - - If you have not already done so, install the hypervisor software on the host. You will need to know which version of the hypervisor software version is supported by &PRODUCT; and what additional configuration is required to ensure the host will work with &PRODUCT;. To find these installation details, see - the appropriate section for your hypervisor in the &PRODUCT; Installation Guide. - Log in to the &PRODUCT; UI as administrator. - In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in which you want to add the host. - Click the Compute tab. In the Clusters node, click View All. - Click the cluster where you want to add the host. - Click View Hosts. - Click Add Host. - Provide the following information. - - Host Name. The DNS name or IP address of the host. - Username. Usually root. - Password. This is the password for the user named above (from your XenServer, KVM, or OVM install). - Host Tags (Optional). Any labels that you use to categorize hosts for ease of maintenance. For example, you can set to the cloud's HA tag (set in the ha.tag global configuration parameter) if you want this host to be used only for VMs with the "high availability" feature enabled. For more information, see HA-Enabled Virtual Machines as well as HA for Hosts. - - There may be a slight delay while the host is provisioned. It should automatically display in the UI. - Repeat for additional hosts. - -
+ There may be a slight delay while the host is provisioned. It should automatically + display in the UI. + + + Repeat for additional hosts. + + +
diff --git a/docs/en-US/management-server-install-systemvm.xml b/docs/en-US/management-server-install-systemvm.xml index c2c12129ef6..6cd1ef7a0ff 100644 --- a/docs/en-US/management-server-install-systemvm.xml +++ b/docs/en-US/management-server-install-systemvm.xml @@ -1,5 +1,5 @@ - %BOOK_ENTITIES; ]> @@ -21,36 +21,51 @@ specific language governing permissions and limitations under the License. --> -
- Prepare the System VM Template - Secondary storage must be seeded with a template that is used for &PRODUCT; system VMs. - When copying and pasting a command, be sure the command has pasted as a single line before executing. Some document viewers may introduce unwanted line breaks in copied text. - - On the Management Server, run one or more of the following cloud-install-sys-tmplt commands to retrieve and decompress the system VM template. Run the command for each hypervisor type that you expect end users to run in this Zone. - If your secondary storage mount point is not named /mnt/secondary, substitute your own mount point name. - If you set the &PRODUCT; database encryption type to "web" when you set up the database, you must now add the parameter -s <management-server-secret-key>. See About Password and Key Encryption. - This process will require approximately 5 GB of free space on the local file system and up to 30 minutes each time it runs. - - For XenServer: - # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F - - For vSphere: - # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optional-management-server-secret-key> -F - - For KVM: - # /usr/lib64/cloud/agent/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F - - + Prepare the System VM Template + Secondary storage must be seeded with a template that is used for &PRODUCT; system + VMs. + + When copying and pasting a command, be sure the command has pasted as a single line before + executing. Some document viewers may introduce unwanted line breaks in copied text. + + + + On the Management Server, run one or more of the following cloud-install-sys-tmplt + commands to retrieve and decompress the system VM template. Run the command for each + hypervisor type that you expect end users to run in this Zone. + If your secondary storage mount point is not named /mnt/secondary, substitute your own + mount point name. + If you set the &PRODUCT; database encryption type to "web" when you set up the database, + you must now add the parameter -s <management-server-secret-key>. See About Password + and Key Encryption. + This process will require approximately 5 GB of free space on the local file system and + up to 30 minutes each time it runs. + + + For XenServer: + # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F - If you are using a separate NFS server, perform this step. If you are using the Management Server as the NFS server, you MUST NOT perform this step. - When the script has finished, unmount secondary storage and remove the created directory. - -# umount /mnt/secondary -# rmdir /mnt/secondary - + + For vSphere: + # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/burbank/burbank-systemvm-08012012.ova -h vmware -s <optional-management-server-secret-key> -F - Repeat these steps for each secondary storage server. + + For KVM: + # /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt -m /mnt/secondary -u http://download.cloud.com/templates/acton/acton-systemvm-02062012.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F - + + + + If you are using a separate NFS server, perform this step. If you are using the + Management Server as the NFS server, you MUST NOT perform this step. + When the script has finished, unmount secondary storage and remove the created + directory. + # umount /mnt/secondary +# rmdir /mnt/secondary + + + Repeat these steps for each secondary storage server. + +
diff --git a/docs/en-US/prepare-system-vm-template.xml b/docs/en-US/prepare-system-vm-template.xml index 160cea426ed..caca4e79464 100644 --- a/docs/en-US/prepare-system-vm-template.xml +++ b/docs/en-US/prepare-system-vm-template.xml @@ -1,5 +1,5 @@ - %BOOK_ENTITIES; ]> diff --git a/docs/en-US/release-notes.xml b/docs/en-US/release-notes.xml index c54b3842d58..fade0ec9045 100644 --- a/docs/en-US/release-notes.xml +++ b/docs/en-US/release-notes.xml @@ -21,28 +21,45 @@ - Submitting Feedback and Getting Help - The Apache CloudStack project has mailing lists for users and developers. These are the official channels of communication for the project and are the best way to get answers about using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users mailing list if you've deployed or are deploying CloudStack into production, and even for test deployments. - The CloudStack developer's mailing list (cloudstack-dev) is for discussions about CloudStack development, and is the best list for discussing possible bugs in CloudStack. Anyone contributing to CloudStack should be on this mailing list. - You can also report bugs in CloudStack using the Apache Defect Tracking System - To posts to the lists, you'll need to be subscribed. See the CloudStack Web site for instructions. + Submitting Feedback and Getting Help + The Apache CloudStack project has mailing lists for users and developers. These are the + official channels of communication for the project and are the best way to get answers about + using and contributing to CloudStack. It's a good idea to subscribe to the cloudstack-users + mailing list if you've deployed or are deploying CloudStack into production, and even for test + deployments. + The CloudStack developer's mailing list (cloudstack-dev) is for discussions about + CloudStack development, and is the best list for discussing possible bugs in CloudStack. + Anyone contributing to CloudStack should be on this mailing list. + You can also report bugs in CloudStack using the Apache Defect Tracking + System + To posts to the lists, you'll need to be subscribed. See the CloudStack Web site + for instructions. Upgrade Instructions
Upgrade from 3.0.2 to 4.0.0-incubating - Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note that some of the steps here are only required if you're using a specific hypervisor. The steps that are hypervisor-specific are called out with a note. + Perform the following to upgrade from version 3.0.2 to version 4.0.0-incubating. Note + that some of the steps here are only required if you're using a specific hypervisor. The + steps that are hypervisor-specific are called out with a note. - Ensure that you query your IP address usage records and process them or make a backup. During the upgrade you will lose the old IP address usage records. + Ensure that you query your IP address usage records and process them or make a + backup. During the upgrade you will lose the old IP address usage records. Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading, any existing IP address usage records in the old format will no longer be available. - - - The following upgrade instructions apply only if you're using VMware hosts. If you're not using VMware hosts, skip this step and move on to step 3: stopping all usage servers. + + + + The following upgrade instructions apply only if you're using VMware hosts. If + you're not using VMware hosts, skip this step and move on to step 3: stopping all + usage servers. + In each zone that includes VMware hosts, you need to add a new system VM template. @@ -121,10 +138,10 @@ - - Watch the screen to be sure that the template downloads successfully and enters the - READY state. Do not proceed until this is successful. - + + Watch the screen to be sure that the template downloads successfully and enters + the READY state. Do not proceed until this is successful. + @@ -136,127 +153,186 @@ # service cloud-management stop - On the MySQL master, take a backup of the MySQL databases. We recommend performing this step even in test upgrades. If there is an issue, this will assist with debugging. - In the following commands, it is assumed that you have set the root password on the database, which is a CloudStack recommended best practice. Substitute your own MySQL root password. + On the MySQL master, take a backup of the MySQL databases. We recommend performing + this step even in test upgrades. If there is an issue, this will assist with + debugging. + In the following commands, it is assumed that you have set the root password on the + database, which is a CloudStack recommended best practice. Substitute your own MySQL + root password. # mysqldump -u root -pmysql_password cloud > cloud-backup.dmp # mysqldump -u root -pmysql_password cloud_usage > cloud-usage-backup.dmp - Either build RPM/DEB packages as detailed in the Installation Guide, or use one of the community provided yum/apt repositories to gain access to the &PRODUCT; binaries. + Either build RPM/DEB packages as detailed in the Installation Guide, or use one of + the community provided yum/apt repositories to gain access to the &PRODUCT; + binaries. - After you have configured an appropriate yum or apt repository, you may execute the one of the following commands as appropriate for your environment in order to upgrade &PRODUCT;: - # yum update cloud-* - # apt-get update + After you have configured an appropriate yum or apt repository, you may execute the + one of the following commands as appropriate for your environment in order to upgrade + &PRODUCT;: # yum update cloud-* + # apt-get update # apt-get upgrade cloud-* - + - If the upgrade output includes a message similar to the following, then some custom content was found in your old components.xml, and you need to merge the two files: + If the upgrade output includes a message similar to the following, then some + custom content was found in your old components.xml, and you need to merge the two + files: warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew Instructions follow in the next step. - If you have made changes to your copy of /etc/cloud/management/components.xml the changes will be preserved in the upgrade. However, you need to do the following steps to place these changes in a new version of the file which is compatible with version 4.0.0-incubating. + If you have made changes to your copy of + /etc/cloud/management/components.xml the changes will be + preserved in the upgrade. However, you need to do the following steps to place these + changes in a new version of the file which is compatible with version + 4.0.0-incubating. - Make a backup copy of /etc/cloud/management/components.xml. For example: + Make a backup copy of /etc/cloud/management/components.xml. + For example: # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup - Copy /etc/cloud/management/components.xml.rpmnew to create a new /etc/cloud/management/components.xml: + Copy /etc/cloud/management/components.xml.rpmnew to create + a new /etc/cloud/management/components.xml: # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml - Merge your changes from the backup file into the new components.xml. + Merge your changes from the backup file into the new + components.xml. # vi /etc/cloud/management/components.xml - - If you have more than one management server node, repeat the upgrade steps on each node. - - - Start the first Management Server. Do not start any other Management Server nodes yet. - # service cloud-management start - 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. + - 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. + If you have more than one management server node, repeat the upgrade steps on each + node. - Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host. + Start the first Management Server. Do not start any other Management Server nodes + yet. + # service cloud-management start + 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. + + 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. + + + + Start all Usage Servers (if they were running on your previous version). Perform + this on each Usage Server host. # service cloud-usage start - 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. + + 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. + - Configure a yum or apt respository containing the &PRODUCT; packages as outlined in the Installation Guide. + Configure a yum or apt respository containing the &PRODUCT; packages as outlined + in the Installation Guide. Stop the running agent. # service cloud-agent stop - Update the agent software with one of the following command sets as appropriate for your environment. - # yum update cloud-* - # apt-get update - # apt-get upgrade cloud-* + Update the agent software with one of the following command sets as appropriate + for your environment. + # yum update cloud-* + # apt-get update + # apt-get upgrade cloud-* Start the agent. # service cloud-agent start - Edit /etc/cloud/agent/agent.properties to change the resource parameter from "com.cloud.agent.resource.computing.LibvirtComputingResource" to "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource". + Edit /etc/cloud/agent/agent.properties to change the + resource parameter from + "com.cloud.agent.resource.computing.LibvirtComputingResource" to + "com.cloud.hypervisor.kvm.resource.LibvirtComputingResource". Start the cloud agent and cloud management services. - When the Management Server is up and running, log in to the CloudStack UI and restart the virtual router for proper functioning of all the features. + When the Management Server is up and running, log in to the CloudStack UI and + restart the virtual router for proper functioning of all the features. - Log in to the CloudStack UI as administrator, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts. + Log in to the CloudStack UI as administrator, and check the status of the hosts. All + hosts should come to Up state (except those that you know to be offline). You may need + to wait 20 or 30 minutes, depending on the number of hosts. - Troubleshooting: If login fails, clear your browser cache and reload the page. + Troubleshooting: If login fails, clear your browser cache and reload the + page. - Do not proceed to the next step until the hosts show in Up state. + Do not proceed to the next step until the hosts show in Up state. If you are upgrading from 3.0.2, perform the following: - Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter. - This port is used by the cloud-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see "Setting Global Configuration Parameters" in the Installation Guide. + Ensure that the admin port is set to 8096 by using the "integration.api.port" + global parameter. + This port is used by the cloud-sysvmadm script at the end of the upgrade + procedure. For information about how to set this parameter, see "Setting Global + Configuration Parameters" in the Installation Guide. Restart the Management Server. - 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. + 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. - Run the cloud-sysvmadm script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the -c and -r arguments. For example: - # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log 2>&1 & - # tail -f sysvm.log - This might take up to an hour or more to run, depending on the number of accounts in the system. + Run the cloud-sysvmadm script to stop, then start, all Secondary + Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on each + management server. Substitute your own IP address of the MySQL instance, the MySQL user + to connect as, and the password to use for that user. In addition to those parameters, + provide the -c and -r arguments. For + example: + # nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > + sysvm.log 2>&1 & + # tail -f sysvm.log + This might take up to an hour or more to run, depending on the number of accounts in + the system. - If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating Installation Guide. + If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version + supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 + and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating + Installation Guide. - Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer v6.0.2 hypervisor hosts. + Now apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to + XenServer v6.0.2 hypervisor hosts. Disconnect the XenServer cluster from CloudStack. - In the left navigation bar of the CloudStack UI, select Infrastructure. Under Clusters, click View All. Select the XenServer cluster and click Actions - Unmanage. - 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. - Wait until the status of the cluster has reached Unmanaged. Use the CloudStack UI to check on the status. When the cluster is in the unmanaged state, there is no connection to the hosts in the cluster. + In the left navigation bar of the CloudStack UI, select Infrastructure. Under + Clusters, click View All. Select the XenServer cluster and click Actions - + Unmanage. + 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. + Wait until the status of the cluster has reached Unmanaged. Use the CloudStack + UI to check on the status. When the cluster is in the unmanaged state, there is no + connection to the hosts in the cluster. To clean up the VLAN, log in to one XenServer host and run: @@ -265,34 +341,51 @@ Now prepare the upgrade by running the following on one XenServer host: /opt/xensource/bin/cloud-prepare-upgrade.sh - If you see a message like "can't eject CD", log in to the VM and unmount the CD, then run this script again. + If you see a message like "can't eject CD", log in to the VM and unmount the CD, + then run this script again. - Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the hotfixes to the host. Place them in a temporary folder such as /tmp. + Upload the hotfix to the XenServer hosts. Always start with the Xen pool master, + then the slaves. Using your favorite file copy utility (e.g. WinSCP), copy the + hotfixes to the host. Place them in a temporary folder such as /tmp. On the Xen pool master, upload the hotfix with this command: xe patch-upload file-name=XS602E003.xsupdate - 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. + 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. - (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. + (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. - Manually live migrate all VMs on this host to another host. First, get a list of the VMs on this host: + Manually live migrate all VMs on this host to another host. First, get a list of + the VMs on this host: # xe vm-list - Then use this command to migrate each VM. Replace the example host name and VM name with your own: - # xe vm-migrate live=true host=host-name vm=VM-name - Troubleshooting - 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. + Then use this command to migrate each VM. Replace the example host name and VM + name with your own: + # xe vm-migrate live=true host=host-name + vm=VM-name + + Troubleshooting + 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. + Apply the hotfix. First, get the UUID of this host: # xe host-list - 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. + 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. xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid - Copy the following files from the CloudStack Management Server to the host. + Copy the following files from the CloudStack Management Server to the + host. @@ -305,15 +398,15 @@ - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py /opt/xensource/sm/NFSSR.py - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/setupxenserver.sh + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh /opt/xensource/bin/setupxenserver.sh - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/make_migratable.sh + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh /opt/xensource/bin/make_migratable.sh @@ -325,11 +418,14 @@ Support Pack. - Download the CSP software onto the XenServer host from one of the following links: + Download the CSP software onto the XenServer host from one of the following + links: For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz - For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz + For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz Extract the file: @@ -353,7 +449,8 @@ Run the following: /opt/xensource/bin/setupxenserver.sh - If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it. + If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or + directory" appears, you can safely ignore it. @@ -361,26 +458,39 @@ for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; - On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs." + On each slave host in the Xen pool, repeat these steps, starting from "manually + live migrate VMs." - Troubleshooting Tip - If passwords which you know to be valid appear not to work after upgrade, or other UI issues are seen, try clearing your browser cache and reloading the UI page. + + Troubleshooting Tip + If passwords which you know to be valid appear not to work after upgrade, or other UI + issues are seen, try clearing your browser cache and reloading the UI page.
Upgrade from 2.2.14 to 4.0 - 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. - Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. Instead of a single record with the assignment and release dates, separate records are generated per aggregation period with start and end dates. After upgrading to 4.0.0-incubating, any existing IP address usage records in the old format will no longer be available. + 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. + Starting in 3.0.2, the usage record format for IP addresses is the same as the rest + of the usage types. Instead of a single record with the assignment and release dates, + separate records are generated per aggregation period with start and end dates. After + upgrading to 4.0.0-incubating, any existing IP address usage records in the old format + will no longer be available. - 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. - KVM Hosts - If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.0.0-incubating. + 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. + + KVM Hosts + If KVM hypervisor is used in your cloud, be sure you completed the step to insert + a valid username and password into the host_details table on each KVM node as + described in the 2.2.14 Release Notes. This step is critical, as the database will be + encrypted after the upgrade to 4.0.0-incubating. @@ -498,20 +608,17 @@ - - Either build RPM/DEB packages as detailed in the Installation Guide, or use one of - the community provided yum/apt repositories to gain access to the &PRODUCT; binaries. + Either build RPM/DEB packages as detailed in the Installation Guide, or use one of + the community provided yum/apt repositories to gain access to the &PRODUCT; binaries. - - After you have configured an appropriate yum or apt repository, you - may execute the one of the following commands as appropriate for your - environment in order to upgrade &PRODUCT;: - # yum update cloud-* - # apt-get update + After you have configured an appropriate yum or apt repository, you may execute the + one of the following commands as appropriate for your environment in order to upgrade + &PRODUCT;: # yum update cloud-* + # apt-get update # apt-get upgrade cloud-* - + If you have made changes to your existing copy of the file components.xml in your @@ -526,13 +633,14 @@ warning: /etc/cloud/management/components.xml created as /etc/cloud/management/components.xml.rpmnew - Make a backup copy of your /etc/cloud/management/components.xml file. For + Make a backup copy of your + /etc/cloud/management/components.xml file. For example: # mv /etc/cloud/management/components.xml /etc/cloud/management/components.xml-backup - Copy /etc/cloud/management/components.xml.rpmnew to create a new - /etc/cloud/management/components.xml: + Copy /etc/cloud/management/components.xml.rpmnew to create + a new /etc/cloud/management/components.xml: # cp -ap /etc/cloud/management/components.xml.rpmnew /etc/cloud/management/components.xml @@ -544,19 +652,19 @@ If you have made changes to your existing copy of the - /etc/cloud/management/db.properties file in your previous-version CloudStack - installation, the changes will be preserved in the upgrade. However, you need to do the - following steps to place these changes in a new version of the file which is compatible - with version 4.0. + /etc/cloud/management/db.properties file in your previous-version + CloudStack installation, the changes will be preserved in the upgrade. However, you need + to do the following steps to place these changes in a new version of the file which is + compatible with version 4.0.0-incubating. - Make a backup copy of your file /etc/cloud/management/db.properties. For - example: + Make a backup copy of your file + /etc/cloud/management/db.properties. For example: # mv /etc/cloud/management/db.properties /etc/cloud/management/db.properties-backup - Copy /etc/cloud/management/db.properties.rpmnew to create a new - /etc/cloud/management/db.properties: + Copy /etc/cloud/management/db.properties.rpmnew to create a + new /etc/cloud/management/db.properties: # cp -ap /etc/cloud/management/db.properties.rpmnew etc/cloud/management/db.properties @@ -612,17 +720,16 @@ as hosts and only on the KVM hosts. - - Configure your CloudStack package repositories as outlined - in the Installation Guide - + Configure your CloudStack package repositories as outlined in the Installation + Guide Stop the running agent. # service cloud-agent stop - Update the agent software with one of the following command sets as appropriate. + Update the agent software with one of the following command sets as + appropriate. # yum update cloud-* # apt-get update @@ -634,11 +741,9 @@ # service cloud-agent start - - Copy the contents of the agent.properties - file to the new agent.properties file - by using the following command - sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties + Copy the contents of the agent.properties file to the new + agent.properties file by using the following command + sed -i 's/com.cloud.agent.resource.computing.LibvirtComputingResource/com.cloud.hypervisor.kvm.resource.LibvirtComputingResource/g' /etc/cloud/agent/agent.properties Start the cloud agent and cloud management services. @@ -717,8 +822,9 @@ Done restarting router(s). If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version - supported by CloudStack 4.0. The supported versions are XenServer 5.6 SP2 and 6.0.2. - Instructions for upgrade can be found in the CloudStack 4.0 Installation Guide. + supported by CloudStack 4.0.0-incubating. The supported versions are XenServer 5.6 SP2 + and 6.0.2. Instructions for upgrade can be found in the CloudStack 4.0.0-incubating + Installation Guide. Apply the XenServer hotfix XS602E003 (and any other needed hotfixes) to XenServer @@ -767,17 +873,27 @@ Done restarting router(s). Then use this command to migrate each VM. Replace the example host name and VM name with your own: # xe vm-migrate live=true host=host-name vm=VM-name - TroubleshootingIf 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. + + Troubleshooting + 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. + Apply the hotfix. First, get the UUID of this host: # xe host-list - 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. - xe patch-apply host-uuid=host-uuid uuid=hotfix-uuid + 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. + xe patch-apply host-uuid=host-uuid + uuid=hotfix-uuid - Copy the following files from the CloudStack Management Server to the host. + Copy the following files from the CloudStack Management Server to the + host. @@ -790,28 +906,34 @@ Done restarting router(s). - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py - /opt/xensource/sm/NFSSR.py + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/xenserver60/NFSSR.py + /opt/xensource/sm/NFSSR.py - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/setupxenserver.sh - /opt/xensource/bin/setupxenserver.sh + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/setupxenserver.sh + /opt/xensource/bin/setupxenserver.sh - /usr/lib64/cloud/agent/scripts/vm/hypervisor/xenserver/make_migratable.sh - /opt/xensource/bin/make_migratable.sh + /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver/make_migratable.sh + /opt/xensource/bin/make_migratable.sh - (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud Support Pack. + (Only for hotfixes XS602E005 and XS602E007) You need to apply a new Cloud + Support Pack. - Download the CSP software onto the XenServer host from one of the following links: - For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz - For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz + Download the CSP software onto the XenServer host from one of the following + links: + For hotfix XS602E005: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E005/56710/xe-phase-2/xenserver-cloud-supp.tgz + For hotfix XS602E007: http://coltrane.eng.hq.xensource.com/release/XenServer-6.x/XS-6.0.2/hotfixes/XS602E007/57824/xe-phase-2/xenserver-cloud-supp.tgz Extract the file: @@ -819,11 +941,13 @@ Done restarting router(s). Run the following script: - # xe-install-supplemental-pack xenserver-cloud-supp.iso + # xe-install-supplemental-pack + xenserver-cloud-supp.iso - If the XenServer host is part of a zone that uses basic networking, disable Open vSwitch (OVS): - # xe-switch-network-backend bridge + If the XenServer host is part of a zone that uses basic networking, disable + Open vSwitch (OVS): + # xe-switch-network-backend bridge @@ -834,16 +958,19 @@ Done restarting router(s). Run the following: /opt/xensource/bin/setupxenserver.sh - If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or directory" appears, you can safely ignore it. + If the message "mv: cannot stat `/etc/cron.daily/logrotate': No such file or + directory" appears, you can safely ignore it. - Run the following: - for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk '{print $NF}'`; do xe pbd-plug uuid=$pbd ; - + Run the following: + for pbd in `xe pbd-list currently-attached=false| grep ^uuid | awk + '{print $NF}'`; do xe pbd-plug uuid=$pbd ; + - On each slave host in the Xen pool, repeat these steps, starting from "manually live migrate VMs." + On each slave host in the Xen pool, repeat these steps, starting from "manually + live migrate VMs." @@ -857,12 +984,25 @@ Done restarting router(s). Apache CloudStack 4.0 includes the following new features:
Inter-VLAN Routing - Inter-VLAN Routing is the capability to route network traffic between VLANs. This feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier applications. These tiers are deployed on different VLANs that can communicate with each other. You can provision VLANs to the tiers your create, and VMs can be deployed on different tiers, such as Web, Application, or Database. The VLANs are connected to a virtual router, which facilitates communication between the VMs. In effect, you can segment VMs by means of VLANs into different networks that can host multi-tier applications. Such segmentation by means of VLANs logically separate application VMs for higher security and lower broadcasts, while remaining physically connected to the same device. + Inter-VLAN Routing is the capability to route network traffic between VLANs. This + feature enables you to set up Virtual Private Clouds (VPC) that can hold multi-tier + applications. These tiers are deployed on different VLANs that can communicate with each + other. You can provision VLANs to the tiers your create, and VMs can be deployed on + different tiers, such as Web, Application, or Database. The VLANs are connected to a + virtual router, which facilitates communication between the VMs. In effect, you can + segment VMs by means of VLANs into different networks that can host multi-tier + applications. Such segmentation by means of VLANs logically separate application VMs for + higher security and lower broadcasts, while remaining physically connected to the same + device. This feature is supported on XenServer and VMware hypervisors.
Site-to-Site VPN - A Site-to-Site VPN connection helps you establish a secure connection from an enterprise datacenter to the cloud infrastructure. This allows users to access the guest VMs by establishing a VPN connection to the virtual router of the account from a device in the datacenter of the enterprise. Having this facility eliminates the need to establish VPN connections to individual VMs. + A Site-to-Site VPN connection helps you establish a secure connection from an + enterprise datacenter to the cloud infrastructure. This allows users to access the guest + VMs by establishing a VPN connection to the virtual router of the account from a device in + the datacenter of the enterprise. Having this facility eliminates the need to establish + VPN connections to individual VMs. The supported endpoints on the remote datacenters are: @@ -875,25 +1015,50 @@ Done restarting router(s).
Local Storage Support for Data Volumes - You can now create data volumes on local storage. The data volume is placed on the same XenServer host as the VM instance that is attached to the data volume. These local data volumes can be attached to virtual machines, detached, re-attached, and deleted just as with the other types of data volume. In earlier releases of CloudStack, only the root disk could be placed in local storage. - Local storage is ideal for scenarios where persistence of data volumes and HA is not required. Some of the benefits include reduced disk I/O latency and cost reduction from using inexpensive local disks. - In order for local volumes to be used, the feature must be enabled for the zone. - You can create a data disk offering for local storage. When a user creates a new VM, they can select this disk offering in order to cause the data disk volume to be placed in local storage. - You can not migrate a VM that has a volume in local storage to a different host, nor migrate the volume itself away to a different host. If you want to put a host into maintenance mode, you must first stop any VMs with local data volumes on that host. - Local storage support for volumes is available for XenServer, KVM, and VMware hypervisors. + You can now create data volumes on local storage. The data volume is placed on the + same XenServer host as the VM instance that is attached to the data volume. These local + data volumes can be attached to virtual machines, detached, re-attached, and deleted just + as with the other types of data volume. In earlier releases of CloudStack, only the root + disk could be placed in local storage. + Local storage is ideal for scenarios where persistence of data volumes and HA is not + required. Some of the benefits include reduced disk I/O latency and cost reduction from + using inexpensive local disks. + In order for local volumes to be used, the feature must be enabled for the + zone. + You can create a data disk offering for local storage. When a user creates a new VM, + they can select this disk offering in order to cause the data disk volume to be placed in + local storage. + You can not migrate a VM that has a volume in local storage to a different host, nor + migrate the volume itself away to a different host. If you want to put a host into + maintenance mode, you must first stop any VMs with local data volumes on that host. + Local storage support for volumes is available for XenServer, KVM, and VMware + hypervisors.
Tags - A tag is a key-value pair that stores metadata about a resource in the cloud. Tags are useful for categorizing resources. For example, you can tag a user VM with a value that indicates the user's city of residence. In this case, the key would be "city" and the value might be "Toronto" or "Tokyo." You can then request CloudStack to find all resources that have a given tag; for example, VMs for users in a given city. - You can tag a user virtual machine, volume, snapshot, guest network, template, ISO, firewall rule, port forwarding rule, public IP address, security group, load balancer rule, project, VPC, network ACL, or static route. You can not tag a remote access VPN. - You can work with tags through the UI or through the new API commands createTags, deleteTags, and listTags. You can define multiple tags for each resource. There is no limit on the number of tags you can define. Each tag can be up to 255 characters long. Users can define tags on the resources they own, and administrators can define tags on any resources in the cloud. - A new optional input parameter, "tags," has been added to many of the list* API commands. The following example shows how to use this new parameter to find all the volumes having tag region=canada OR tag city=Toronto: + A tag is a key-value pair that stores metadata about a resource in the cloud. Tags are + useful for categorizing resources. For example, you can tag a user VM with a value that + indicates the user's city of residence. In this case, the key would be "city" and the + value might be "Toronto" or "Tokyo." You can then request CloudStack to find all resources + that have a given tag; for example, VMs for users in a given city. + You can tag a user virtual machine, volume, snapshot, guest network, template, ISO, + firewall rule, port forwarding rule, public IP address, security group, load balancer + rule, project, VPC, network ACL, or static route. You can not tag a remote access + VPN. + You can work with tags through the UI or through the new API commands createTags, + deleteTags, and listTags. You can define multiple tags for each resource. There is no + limit on the number of tags you can define. Each tag can be up to 255 characters long. + Users can define tags on the resources they own, and administrators can define tags on any + resources in the cloud. + A new optional input parameter, "tags," has been added to many of the list* API + commands. The following example shows how to use this new parameter to find all the + volumes having tag region=canada OR tag city=Toronto: command=listVolumes - &listAll=true - &tags[0].key=region - &tags[0].value=canada - &tags[1].key=city - &tags[1].value=Toronto +&listAll=true +&tags[0].key=region +&tags[0].value=canada +&tags[1].key=city +&tags[1].value=Toronto The following API commands have the new "tags" input parameter: @@ -945,7 +1110,8 @@ Done restarting router(s).
AWS API Changes for Tags - Some changes have been made to the Amazon Web Services API compatibility support in order to accommodate the new tagging feature. + Some changes have been made to the Amazon Web Services API compatibility support in + order to accommodate the new tagging feature. New APIs: @@ -1015,7 +1181,8 @@ Done restarting router(s). Output now shows tags defined for each image. - The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key + The following filters can now be passed in to limit the output result set: + tag-key, tag-value and tag:key @@ -1024,14 +1191,16 @@ Done restarting router(s). Output now shows tags defined for each image. - The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key + The following filters can now be passed in to limit the output result set: + tag-key, tag-value and tag:key ec2-describe-volumes Output now shows tags defined for each image. - The following filters can now be passed in to limit the output result set: tag-key, tag-value and tag:key + The following filters can now be passed in to limit the output result set: + tag-key, tag-value and tag:key @@ -1040,12 +1209,21 @@ Done restarting router(s).
Secure Console Access on XenServer - 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. + 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.
Stopped VM - 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. - A new request parameter, startVM, is introduced in the deployVm API to support the stopped VM feature. The possible values are: + 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. + A new request parameter, startVM, is introduced in the deployVm API to support the + stopped VM feature. The possible values are: true - The VM starts as a part of the VM deployment @@ -1057,7 +1235,11 @@ Done restarting router(s).
Uploading an Existing Volume to a Virtual Machine - 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. + 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. This functionality is supported for the following hypervisors: @@ -1079,25 +1261,43 @@ Done restarting router(s).
Dedicated High-Availability Hosts - 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. + 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.
Support for Amazon Web Services API - 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 CloudStack 4.0.0-incubating, this software is installed automatically along with CloudStack 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. + 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 CloudStack 4.0.0-incubating, this software is installed automatically along with + CloudStack 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.
The Nicira NVP Plugin - The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating this plug-in supports the Connectivity service. This service is responsible for creating Layer 2 networks supporting the networks created by guests. When a tenant creates a new network, instead of a traditional VLAN, a logical network will be created by sending the appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira NVP versions 2.1.0, 2.2.0 and 2.2.1. + The Nicira NVP plug-in allows CloudStack to use the Nicira solution for virtualized + network as a provider for CloudStack networks and services. In CloudStack 4.0.0-incubating + this plug-in supports the Connectivity service. This service is responsible for creating + Layer 2 networks supporting the networks created by guests. When a tenant creates a new + network, instead of a traditional VLAN, a logical network will be created by sending the + appropriate calls to the Nicira NVP Controller. The plug-in has been tested with Nicira + NVP versions 2.1.0, 2.2.0 and 2.2.1.
Support for CAStor Cluster - CloudStack 4.0 supports using a CAStor cluster as the back-end storage system for a - CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends the existing - storage classes and allows the storage configuration attribute to point to a CAStor - cluster. This feature makes use of the CloudStack server's local disk to spool files - before writing them to CAStor when handling the PUT operations. However, a file must be - successfully written into the CAStor cluster prior to the return of a success code to the - S3 client to ensure that the transaction outcome is correctly reported. + CloudStack 4.0.0-incubating supports using a CAStor cluster as the back-end storage + system for a CloudStack S3 front-end. The CAStor back-end storage for CloudStack extends + the existing storage classes and allows the storage configuration attribute to point to a + CAStor cluster. This feature makes use of the CloudStack server's local disk to spool + files before writing them to CAStor when handling the PUT operations. However, a file must + be successfully written into the CAStor cluster prior to the return of a success code to + the S3 client to ensure that the transaction outcome is correctly reported. The S3 multipart file upload is not supported in this release. You are prompted with proper error message if a multipart upload is attempted.
@@ -1116,13 +1316,21 @@ Done restarting router(s).
Rados Block Device Support for KVM - You can now use Rados Block Device (RBD) to run instances on Apache CloudStack 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least 0.10 with RBD enabled on the KVM host - Create a disk offering for RBD so that you can ensure that StoragePoolAllocator chooses the RBD pool to deploy instances. + You can now use Rados Block Device (RBD) to run instances on Apache CloudStack + 4.0.0-incubating. This can be done by adding a RBD pool as primary storage. Before using + RBD, ensure that Qemu is compiled with RBD enabled, and the libvirt version is at least + 0.10 with RBD enabled on the KVM host + Create a disk offering for RBD so that you can ensure that StoragePoolAllocator + chooses the RBD pool to deploy instances.
- Issues Fixed in 4.0.0-incubating - Many bugs include a defect number that reflects the bug number that was held in the bug tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so some of the bugs that are referenced here may not be available to view. However, we are still including them for completeness. + Issues Fixed in 4.0.0-incubating + Many bugs include a defect number that reflects the bug number that was held in the bug + tracker run by Citrix (bugs.cloudstack.org). The Apache CloudStack project now uses Jira to manage its bugs, so + some of the bugs that are referenced here may not be available to view. However, we are + still including them for completeness. @@ -1889,9 +2097,9 @@ Done restarting router(s). CS-15789 Invalid global setting prevents management server to restart. For - example, if you configure the "project.invite.timeout" parameter to - "300" and attempt to restart management server, it fails without - throwing a warning or setting the value to the default. + example, if you configure the "project.invite.timeout" parameter to "300" and + attempt to restart management server, it fails without throwing a warning or + setting the value to the default. @@ -2061,8 +2269,8 @@ Done restarting router(s). CS-15476 - The 2.2.14 to 4.0 upgrade fails if multiple untagged physical networks exist - before the upgrade. + The 2.2.14 to 4.0.0-incubating upgrade fails if multiple untagged physical + networks exist before the upgrade. @@ -2070,8 +2278,8 @@ Done restarting router(s). CS-15407 - After the 2.2.14 to 4.0 upgrade, VLAN allocation on multiple physical networks - does not happen as expected. + After the 2.2.14 to 4.0.0-incubating upgrade, VLAN allocation on multiple + physical networks does not happen as expected. To workaround this issue, follow the instructions given below: @@ -2238,14 +2446,14 @@ Done restarting router(s). &tags[0].key=region &tags[0].value=canada &tags[1].key=city -&tags[1].value=Toronto +&tags[1].value=Toronto deleteTags. Remove tags from one or more resources. Example: command=deleteTags &resourceIds=1,12 &resourceType=Snapshot -&tags[0].key=city +&tags[0].key=city listTags (Show currently defined resource tags)