Citrix CloudPlatform (powered by Apache CloudStack) Version 4.2 Release Notes. Revised September 02, :45 am Pacific

(1)

Citrix CloudPlatform

(powered by Apache

CloudStack) Version

4.2 Release Notes

(2)

Citrix CloudPlatform (powered by Apache CloudStack) Version

4.2 Release Notes

Revised September 02, 2013 01:45 am Pacific

© 2013 Citrix Systems, Inc. All rights reserved. Specifications are subject to change without notice. Citrix Systems, Inc., the Citrix logo, Citrix XenServer, Citrix XenCenter, and CloudPlatform are trademarks or registered trademarks of Citrix Systems, Inc. All other brands or products are trademarks or registered trademarks of their respective holders.

(3)

Draft Draft

1. Submitting Feedback and Getting Help 1

2. Changes to Supported Operating Systems and Hypervisors 3

2.1. OS Supported for Management Server ... 3

2.2. Hypervisor Versions Supported ... 3

2.3. New Supported OS for Guest Virtual Machines ... 3

3. Upgrade Instructions 5

3.1. Upgrade from 3.0.x to 4.2 ... 5

3.2. Upgrade from 2.2.x to 4.2 ... 10

3.3. Upgrade from 2.1.x to 4.2 ... 17

3.4. Upgrading and Hotfixing XenServer Hypervisor Hosts ... 17

3.4.1. Upgrading to a New XenServer Version ... 17

3.4.2. Applying Hotfixes to a XenServer Cluster ... 19

4. About This New Release 23

5. What's New in 4.2 25

5.1. Features to Support Heterogeneous Workloads ... 25

5.1.1. Regions ... 25

5.1.2. Object Storage Plugin Architecture ... 26

5.1.3. Zone-Wide Primary Storage Target ... 26

5.1.4. VMware Datacenter Now Visible As a CloudPlatform Zone ... 26

5.2. Third-Party UI Plugin Framework ... 26

5.3. Networking Enhancements ... 29

5.3.1. IPv6 (Technical Preview) ... 29

5.3.2. Portable IPs ... 29

5.3.3. N-Tier Applications ... 29

5.3.4. Assigning VLANs to Isolated Networks ... 31

5.3.5. Persistent Networks ... 32

5.3.6. Cisco VNMC Support ... 32

5.3.7. VMware vNetwork Distributed vSwitch ... 33

5.3.8. IP Reservation in Isolated Guest Networks ... 33

5.3.9. Dedicated Resources: Public IP Addresses and VLANs Per Account ... 34

5.3.10. Egress Firewall Rules ... 35

5.3.11. Non-Contiguous VLAN Ranges ... 35

5.3.12. Isolation in Advanced Zone Using Private VLAN ... 35

5.3.13. Configuring Multiple IP Addresses on a Single NIC ... 36

5.3.14. Adding Multiple IP Ranges ... 36

5.3.15. Reconfiguring Networks in VMs ... 37

5.3.16. Global Server Load Balancing ... 37

5.4. Host and Virtual Machine Enhancements ... 37

5.4.1. VMware DRS Support ... 37

5.4.2. Windows 8 and Windows Server as VM Guest OS ... 37

5.4.3. Configuring Usage of Linked Clones on VMware ... 38

5.4.4. VM Deployment Rules ... 38

5.4.5. CPU and Memory Scaling for Running VMs ... 38

5.4.6. CPU and Memory Over-Provisioning ... 38

5.4.7. Kickstart Installation for Bare Metal Provisioning ... 39

5.4.8. Enhanced Bare Metal Support on Cisco UCS ... 39

5.4.9. Changing a VM's Base Image ... 39

(4)

5.5. Monitoring, Maintenance, and Operations Enhancements ... 41

5.5.1. Publish and Subscribe for Event Notification ... 41

5.5.2. Deleting and Archiving Events and Alerts ... 42

5.5.3. Increased Granularity for Configuration Parameters ... 43

5.5.4. API Request Throttling ... 43

5.5.5. Sending Alerts to External SNMP and Syslog Managers ... 43

5.5.6. Health Checks for Load Balanced Instances ... 43

5.5.7. Change Account Ownership of Virtual Machines ... 44

5.5.8. Changing the Default Password Encryption ... 44

5.5.9. Resizing Volumes ... 44

5.5.10. VMware Volume Snapshot Improved Performance ... 44

5.5.11. Storage Migration: XenMotion and vMotion ... 45

5.5.12. Load Balancing using External Provider on Shared VLANs ... 45

5.5.13. Private Pod, Cluster, or Host ... 45

5.5.14. Log Collection Utility cloud-bugtool ... 45

6. Fixed Issues 47

6.1. Issues Fixed in 4.2 ... 47

7. Known Issues 51

8. API Changes from 3.0 to 4.2 53

8.1. Added API Commands in 4.2 ... 53

8.2. Changed API Commands in 4.2 ... 57

(5)

Draft Chapter 1. Draft

Submitting Feedback and Getting Help

The support team is available to help customers plan and execute their installations. To contact the support team, log in to the Support Portal1 by using the account credentials you received when you purchased your support contract.

(6)

(7)

Changes to Supported Operating

Systems and Hypervisors

This section describes the operating systems and hypervisors that have been newly tested and certified compatible with CloudPlatform 4.2, as well as which previously supported versions have been retired. Some earlier OS and hypervisor versions are also still supported for use with 4.2. For a complete list, see the System Requirements section of the CloudPlatform 4.2 Installation Guide.

2.1. OS Supported for Management Server

The following new OS support has been added:

• RHEL 6.3

• RHEL 6.4

For more information, see Minimum System Requirements in the CloudPlatform Installation Guide.

2.2. Hypervisor Versions Supported

The following new hypervisor support has been added:

• XenServer 6.2

• KVM on RHEL 6.3

• Bare metal hosts are supported, which have no hypervisor. These hosts can run the following operating systems:

• RHEL or CentOS, v6.2 or 6.3

Note

Use libvirt version 0.9.10 for CentOS 6.3

• Fedora 17

• Ubuntu 12.04

For more information, see the Hypervisor Compatibility Matrix in the CloudPlatform Installation Guide.

2.3. New Supported OS for Guest Virtual Machines

• Windows 8 and Windows Server 2012 are now supported for guest virtual machines on KVM, XenServer, and VMware. See Section 5.4.2, “Windows 8 and Windows Server as VM Guest OS”.

(8)

(9)

Upgrade Instructions

3.1. Upgrade from 3.0.x to 4.2

Perform the following to upgrade from version 3.0.0, 3.0.1, 3.0.2, 3.0.3, 3.0.4, 3.0.5, 3.0.6, or 3.0.7 to version 4.2.

1. If you are upgrading from 3.0.0 or 3.0.1, ensure that you query your IP address usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.

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.

2. While running the 3.0.x system, log in to the UI as root administrator.

3. Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone

a. In the left navigation bar, click Templates.

b. In Select view, click Templates.

c. Click Register template.

The Register template dialog box is displayed.

d. In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):

Hypervisor Description

XenServer Name: systemvm-xenserver-4.2

Description: systemvm-xenserver-4.2

URL: http://download.cloud.com/ templates/4.2/

systemvmtemplate-2013-07-12-master-xen.vhd.bz2

Zone: Choose the zone where this hypervisor is used

Hypervisor: XenServer

Format: VHD

OS Type: Debian GNU/Linux 7.0 (32-bit)

(10)

Featured: no

KVM Name: systemvm-kvm-4.2

Description: systemvm-kvm-4.2

URL: http://download.cloud.com/ templates/4.2/

systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

Hypervisor: KVM

Format: QCOW2

Extractable: no

Password Enabled: no

Public: no

Featured: no

VMware Name: systemvm-vmware-4.2

Description: systemvm-vmware-4.2

URL: http://download.cloud.com/ templates/4.2/systemvmtemplate-4.2-vh7.ova

Hypervisor: VMware

Format: OVA

Extractable: no

Public: no

Featured: no

e. Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful

f. If you use more than one type of hypervisor in your cloud, repeat these steps to download the system VM template for each hypervisor type.

(11)

Draft Upgrade from 3.0.x to 4.2

Warning

If you do not repeat the steps for each hypervisor type, the upgrade will fail.

4. Stop all Usage Servers if running. Run this on all Usage Server hosts.

# service cloudstack-usage stop

5. Stop the Management Servers. Run this on all Management Server hosts.

# service cloudstack-management stop

6. 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 CloudPlatform recommended best practice. Substitute your own MySQL root password.

# mysqldump -u root -p<mysql_password> cloud >> cloudstack-backup.dmp

# mysqldump -u root -p<mysql_password> cloudstack_usage > cloudstack-usage-backup.dmp

7. (RHEL/CentOS 5.x) If you are upgrading with the Usage Server on RHEL/CentOS 5.x, run the following command. This is to work around a dependency on JSVC. (CLOUDSTACK-3765)

rpm -Uvh http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm

8. Download CloudPlatform 4.2 onto the management server host where it will run. Get the software from the following link:

https://www.citrix.com/English/ss/downloads/.

You need a My Citrix Account1.

9. Upgrade the CloudPlatform packages. You should have a file in the form of “CloudStack-4.2-N-OSVERSION.tar.gz”. Untar the file, then run the install.sh script inside it. Replace the file and directory names below with those you are using:

# tar xzf CloudStack-4.2-N-OSVERSION.tar.gz # cd CloudStack-4.2-N-OSVERSION

# ./install.sh

You should see a few messages as the installer prepares, followed by a list of choices.

(12)

>U

You should see some output as the upgrade proceeds, ending with a message like "Complete! Done."

11. Repeat steps 8 - 9 on each management server node.

12. Start the first Management Server. Do not start any other Management Server nodes yet.

# service cloudstack-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.

Note

Failing to restart the Management Server indicates a problem in the upgrade. Restarting the Management Server without any issues indicates that the upgrade is successfully completed.

13. Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.

# service cloudstack-usage start

Note

After upgrade from 3.0.4 to 4.2, if the usage server fails to restart then copy db.properties from /etc/cloudstack/management to /etc/cloudstack/usage. Then start the Usage Server.

14. (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.

a. Copy the CloudPlatform 4.2 tar file to the host, untar it, and change directory to the resulting directory.

b. Stop the running agent.

# service cloudstack-agent stop

c. Update the agent software.

# ./install.sh

(13)

e. Edit /etc/cloudstack/agent/agent.properties to change the resource parameter from com.cloud.agent.resource.computing.LibvirtComputingResource to com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.

f. Start the agent.

# service cloudstack-agent start

g. Start the Management Server.

15. Log in to the CloudPlatform 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.

Note

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. If the hosts do not come to the Up state, contact support.

16. If you are upgrading from 3.0.1 or 3.0.2, perform the following:

a. Ensure that the admin port is set to 8096 by using the "integration.api.port" global parameter.

This port is used by the cloudstack-sysvmadm script at the end of the upgrade procedure. For information about how to set this parameter, see “Edit the Global Configuration Settings” in the Advanced Installation Guide.

b. Restart the Management Server.

Note

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

17. Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers. Run the script once on one management server. 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 "-a" argument. For example:

# nohup cloudstack-sysvmadm -d 192.168.1.5 -u cloud -p password -a > 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.

18. (XenServer only) If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudPlatform 4.2 and apply any required hotfixes. Instructions for upgrading XenServer software and applying hotfixes can be found in Section 3.4, “Upgrading and Hotfixing XenServer Hypervisor Hosts”.

(14)

Note

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.

Note

(VMware only) After upgrade, whenever you add a new VMware cluster to a zone that was created with a previous version of CloudPlatform, the fields vCenter host, vCenter Username, vCenter Password, and vCenter Datacenter are required. The Add Cluster dialog in the CloudPlatform user interface incorrectly shows them as optional, and will allow you to proceed with adding the cluster even though these important fields are blank. If you do not provide the values, you will see an error message like "Your host and/or path is wrong. Make sure it's of the format http://hostname/path".

3.2. Upgrade from 2.2.x to 4.2

1. Ensure that you query your IP address usage records and process them; for example, issue invoices for any usage that you have not yet billed users for.

Starting in 3.0.2, the usage record format for IP addresses is the same as the rest of the usage types. See CS-82222. 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.2, any existing IP address usage records in the old format will no longer be available.

2. 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 Notes3.

Note

(KVM only) If KVM hypervisor is used in your cloud, be sure you completed the step to insert a valid username and password into the host_details table on each KVM node as described in the 2.2.14 Release Notes. This step is critical, as the database will be encrypted after the upgrade to 4.2.

3. While running the 2.2.x system (which by this step should be at version 2.2.14 or greater), log in to the UI as root administrator.

4. Using the UI, add a new System VM template for each hypervisor type that is used in your cloud. In each zone, add a system VM template for each hypervisor used in that zone

a. In the left navigation bar, click Templates.

2

(15)

b. In Select view, click Templates.

c. Click Register template.

The Register template dialog box is displayed.

d. In the Register template dialog box, specify the following values depending on the hypervisor type (do not change these):

XenServer Name: systemvm-xenserver-4.2

Description: systemvm-xenserver-4.2

URL: http://download.cloud.com/templates/4.2/ systemvmtemplate-2013-07-12-master-xen.vhd.bz2

Hypervisor: XenServer

Format: VHD

Extractable: no

Public: no

Featured: no

KVM Name: systemvm-kvm-4.2

Description: systemvm-kvm-4.2

URL: http://download.cloud.com/templates/4.2/

systemvmtemplate-2013-06-12-master-kvm.qcow2.bz2

Hypervisor: KVM

Format: QCOW2

Extractable: no

Public: no

Featured: no

(16)

URL: http://download.cloud.com/templates/4.2/ systemvmtemplate-4.2-vh7.ova

Hypervisor: VMware

Format: OVA

Extractable: no

Public: no

Featured: no

e. Watch the screen to be sure that the template downloads successfully and enters the READY state. Do not proceed until this is successful

f. If you use more than one type of hypervisor in your cloud, repeat these steps to download the system VM template for each hypervisor type.

Warning

If you do not repeat the steps for each hypervisor type, the upgrade will fail.

5. Stop all Usage Servers if running. Run this on all Usage Server hosts.

# service cloudstack-usage stop

6. Stop the Management Servers. Run this on all Management Server hosts.

# service cloudstack-management stop

7. 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 CloudPlatform recommended best practice. Substitute your own MySQL root password.

# mysqldump -u root -p<mysql_password> cloud >> cloudstack-backup.dmp

# mysqldump -u root -p<mysql_password> cloud_usage > cloudstack-usage-backup.dmp

8. (RHEL/CentOS 5.x) If you are upgrading with the Usage Server on RHEL/CentOS 5.x, run the following command. This is to work around a dependency on JSVC. (CLOUDSTACK-3765)

(17)

rpm -Uvh http://download.cloud.com/support/jsvc/jakarta-commons-daemon-jsvc-1.0.1-8.9.el6.x86_64.rpm

9. Download CloudPlatform 4.2 onto the management server host where it will run. Get the software from the following link:

https://www.citrix.com/English/ss/downloads/

You need a My Citrix Account4.

10. Upgrade the CloudPlatform packages. You should have a file in the form of “CloudStack-4.2-N-OSVERSION.tar.gz”. Untar the file, then run the install.sh script inside it. Replace the file and directory names below with those you are using:

# tar xzf CloudStack-4.2-N-OSVERSION.tar.gz # cd CloudStack-4.2-N-OSVERSION

# ./install.sh

You should see a few messages as the installer prepares, followed by a list of choices.

11. Choose "U" to upgrade the package.

> U

12. If you have made changes to your existing copy of the file components.xml in your previous-version CloudPlatform 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.2.

Note

How will you know whether you need to do this? If the upgrade output in the previous step included a message like the following, then some custom content was found in your old components.xml, and you need to merge the two files:

warning: /etc/cloud.rpmsave/management/components.xml created as /etc/cloudstack/ management/components.xml.rpmnew

a. Make a backup copy of your /etc/cloudstack/management/components.xml file. For example:

# mv /etc/cloudstack/management/components.xml /etc/cloudstack/management/ components.xml-backup

b. Copy /etc/cloudstack/management/components.xml.rpmnew to create a new /etc/cloudstack/ management/components.xml:

(18)

# cp -ap /etc/cloudstack/management/components.xml.rpmnew /etc/cloudstack/management/ components.xml

c. Merge your changes from the backup file into the new components.xml file.

# vi /etc/cloudstack/management/components.xml

13. If you have made changes to your existing copy of the /etc/cloudstack/management/db.properties file in your previous-version CloudPlatform 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.2.

a. Make a backup copy of your file /etc/cloudstack/management/db.properties. For example:

# mv /etc/cloudstack/management/db.properties /etc/cloudstack/management/ db.properties-backup

b. Copy /etc/cloudstack/management/db.properties.rpmnew to create a new /etc/cloudstack/ management/db.properties:

# cp -ap /etc/cloudstack/management/db.properties.rpmnew etc/cloudstack/management/ db.properties

c. Merge your changes from the backup file into the new db.properties file.

# vi /etc/cloudstack/management/db.properties

14. On the management server node, run the following command. It is recommended that you use the command-line flags to provide your own encryption keys. See Password and Key Encryption in the Installation Guide.

# cloudstack-setup-encryption -e <encryption_type> -m <management_server_key> -k <database_key>

When used without arguments, as in the following example, the default encryption type and keys will be used:

• (Optional) For encryption_type, use file or web to indicate the technique used to pass in the database encryption password. Default: file.

• (Optional) For management_server_key, substitute the default key that is used to encrypt confidential parameters in the properties file. Default: password. It is highly recommended that you replace this with a more secure value

• (Optional) For database_key, substitute the default key that is used to encrypt confidential parameters in the CloudPlatform database. Default: password. It is highly recommended that you replace this with a more secure value.

15. Repeat steps 9 - 14 on every management server node. If you provided your own encryption key in step 14, use the same key on all other management servers.

(19)

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.

17. Start all Usage Servers (if they were running on your previous version). Perform this on each Usage Server host.

# service cloudstack-usage start

18. (KVM only) Additional steps are required for each KVM host. These steps will not affect running guests in the cloud. These steps are required only for clouds using KVM as hosts and only on the KVM hosts.

Note

After the 2.2.13 to 3.0.x upgrade on a KVM machine, Ctrl+Alt+Del button on the console view of a VM doesn't work. Use Ctrl+Alt+Insert to log in to the console of the VM.

a. Copy the CloudPlatform 4.2 .tgz download to the host, untar it, and cd into the resulting directory.

b. Stop the running agent.

# service cloudstack-agent stop

c. Update the agent software.

# ./install.sh

d. Choose "U" to update the packages.

e. Edit /etc/cloudstack/agent/agent.properties to change the resource parameter from com.cloud.agent.resource.computing.LibvirtComputingResource to com.cloud.hypervisor.kvm.resource.LibvirtComputingResource.

f. Start the agent.

# service cloudstack-agent start

Note

After upgrade from 3.0.4 to 4.2, if the usage server fails to restart then copy db.properties from /etc/cloudstack/management to /etc/cloudstack/usage. Then start the Usage Server.

(20)

19. Log in to the CloudPlatform UI as admin, and check the status of the hosts. All hosts should come to Up state (except those that you know to be offline). You may need to wait 20 or 30 minutes, depending on the number of hosts.

Do not proceed to the next step until the hosts show in the Up state. If the hosts do not come to the Up state, contact support.

20. Run the following script to stop, then start, all Secondary Storage VMs, Console Proxy VMs, and virtual routers.

a. Run the command once on one management server. Substitute your own IP address of the MySQL instance, the MySQL user to connect as, and the password to use for that user. In addition to those parameters, provide the "-c" and "-r" arguments. For example:

# nohup cloudstack-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.

b. After the script terminates, check the log to verify correct execution:

# tail -f sysvm.log

The content should be like the following:

Stopping and starting 1 secondary storage vm(s)... Done stopping and starting secondary storage vm(s) Stopping and starting 1 console proxy vm(s)... Done stopping and starting console proxy vm(s). Stopping and starting 4 running routing vm(s)... Done restarting router(s).

21. If you would like additional confirmation that the new system VM templates were correctly applied when these system VMs were rebooted, SSH into the System VM and check the version.

Use one of the following techniques, depending on the hypervisor.

XenServer or KVM:

SSH in by using the link local IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own link local IP.

Run the following commands on the XenServer or KVM host on which the system VM is present:

# ssh -i <private-key-path> <link-local-ip> -p 3922 # cat /etc/cloudstack-release

The output should be like the following:

(21)

ESXi

SSH in using the private IP address of the system VM. For example, in the command below, substitute your own path to the private key used to log in to the system VM and your own private IP.

Run the following commands on the Management Server:

# ssh -i <private-key-path> <private-ip> -p 3922 # cat /etc/cloudstack-release

The output should be like the following:

Cloudstack Release 4.2 Mon Aug 12 15:10:04 PST 2012

22. (XenServer only) If needed, upgrade all Citrix XenServer hypervisor hosts in your cloud to a version supported by CloudPlatform 4.2 and apply any required hotfixes. Instructions for

upgrading and applying hotfixes can be found in Section 3.4, “Upgrading and Hotfixing XenServer Hypervisor Hosts”.

Note

(VMware only) After upgrade, whenever you add a new VMware cluster to a zone that was created with a previous version of CloudPlatform, the fields vCenter host, vCenter Username, vCenter Password, and vCenter Datacenter are required. The Add Cluster dialog in the CloudPlatform user interface incorrectly shows them as optional, and will allow you to proceed with adding the cluster even though these important fields are blank. If you do not provide the values, you will see an error message like "Your host and/or path is wrong. Make sure it's of the format http://hostname/path".

3.3. Upgrade from 2.1.x to 4.2

Direct upgrades from version 2.1.0 - 2.1.10 to 4.2 are not supported. It must first be upgraded to version 2.2.14. For information on how to upgrade from 2.1.x to 2.2.14, see the CloudPlatform 2.2.14 Release Notes.

3.4. Upgrading and Hotfixing XenServer Hypervisor Hosts

In CloudPlatform 4.2, you can upgrade XenServer hypervisor host software without having to disconnect the XenServer cluster. You can upgrade XenServer 5.6 GA, 5.6 FP1, or 5.6 SP2 to any newer version that is supported by CloudPlatform. The actual upgrade is described in XenServer documentation, but there are some additional steps you must perform before and after the upgrade.

3.4.1. Upgrading to a New XenServer Version

To upgrade XenServer hosts when running CloudPlatform 4.2:

1. Edit the file /etc/cloudstack/management/environment.properties and add the following line:

(22)

2. Restart the Management Server to put the new setting into effect.

3. Find the hostname of the master host in your XenServer cluster (pool):

a. Run the following command on any host in the pool, and make a note of the host-uuid of the master host:

# xe pool-list

b. Now run the following command, and find the host that has a host-uuid that matches the master host from the previous step. Make a note of this host's hostname. You will need to input it in a later step.

# xe host-list

4. On CloudPlatform, put the master host into maintenance mode. Use the hostname you discovered in the previous step.

Note

In the latest XenServer upgrade procedure, even after putting the master host into maintenance mode, the master host continues to stay as master.

Any VMs running on this master will be automatically migrated to other hosts, unless there is only one UP host in the cluster. If there is only one UP host, putting the host into maintenance mode will stop any VMs running on the host.

5. Disconnect the XenServer cluster from CloudPlatform. It will remain disconnected only long enough to upgrade one host.

a. Log in to the CloudPlatform UI as root.

b. Navigate to the XenServer cluster, and click Actions – Unmanage.

c. Watch the cluster status until it shows Unmanaged.

6. Upgrade the XenServer software on the master host:

a. Insert the XenXerver 6.0.2 CD.

b. Reboot the host.

c. Upgrade to the newer version of XenServer. Use the steps in XenServer documentation.

7. Cancel the maintenance mode on the master host.

8. Reconnect the XenServer cluster to CloudPlatform.

(23)

Draft Applying Hotfixes to a XenServer Cluster

c. Watch the status to see that all the hosts come up.

9. Upgrade the slave hosts in the cluster:

a. Put a slave host into maintenance mode.

Wait until all the VMs are migrated to other hosts.

b. Upgrade the XenServer software on the slave.

c. Cancel maintenance mode for the slave.

d. Repeat steps a through c for each slave host in the XenServer pool.

10. You might need to change the OS type settings for VMs running on the upgraded hosts, if any of the following apply:

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

3.4.2. Applying Hotfixes to a XenServer Cluster

1. Edit the file /etc/cloudstack/management/environment.properties and add the following line:

manage.xenserver.pool.master=false

2. Restart the Management Server to put the new setting into effect.

3. Find the hostname of the master host in your XenServer cluster (pool):

a. Run the following command on any host in the pool, and make a note of the host-uuid of the master host:

# xe pool-list

b. Now run the following command, and find the host that has a host-uuid that matches the master host from the previous step. Make a note of this host's hostname. You will need to input it in a later step.

(24)

4. On CloudPlatform, put the master host into maintenance mode. Use the hostname you discovered in the previous step.

Any VMs running on this master will be automatically migrated to other hosts, unless there is only one UP host in the cluster. If there is only one UP host, putting the host into maintenance mode will stop any VMs running on the host.

5. Disconnect the XenServer cluster from CloudPlatform. It will remain disconnected only long enough to hotfix one host.

b. Navigate to the XenServer cluster, and click Actions – Unmanage.

c. Watch the cluster status until it shows Unmanaged.

6. Hotfix the master host:

a. Add the XenServer hot fixes to the master host.

i. Assign a UUID to the update file:

xe patch-upload file-name=XS602E015.xsupdate

The command displays the UUID of the update file:

33af688e-d18c-493d-922b-ec51ea23cfe9

ii. Repeat the xe patch-upload command for all other XenServer updates: XS602E004.xsupdate, XS602E005.xsupdate.

Take a note of the UUIDs of the update files. The UUIDs are required in the next step.

b. Apply XenServer hot fixes to master host:

xe patch-apply host-uuid=<master uuid> uuid=<hotfix uuid>

c. Repeat xe patch-apply command for all the hot fixes.

d. Install the required CSP files.

xe-install-supplemental-pack <csp-iso-file>

e. Restart the master host.

7. Cancel the maintenance mode on the master host.

8. Reconnect the XenServer cluster to CloudPlatform.

b. Navigate to the XenServer cluster, and click Actions – Manage.

(25)

Draft Applying Hotfixes to a XenServer Cluster

a. Put a slave host into maintenance mode.

Wait until all the VMs are migrated to other hosts.

b. Apply the XenServer hot fixes to the slave host:

xe patch-apply host-uuid=<master uuid> uuid=<hotfix uuid>

c. Repeat Step a through b for each slave host in the XenServer pool.

d. Install the required CSP files.

xe-install-supplemental-pack <csp-iso-file>

e. Restart the slave hosts.

Wait until all the slave hosts are up. It might take several minutes for the hosts to come up.

10. Cancel the maintenance mode on the slave hosts.

11. You might need to change the OS type settings for VMs running on the upgraded hosts, if any of the following apply:

• 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 GA or 5.6 FP1 to XenServer 6.0.2, change any VMs that have the OS type CentOS 5.5 (32-bit), CentOS 5.6 (32-bit), CentOS 5.7 (32-bit), Oracle Enterprise Linux 5.5 (32-bit), Oracle Enterprise Linux 5.6 (32-bit), Oracle Enterprise Linux 5.7 (32-bit), Red Hat Enterprise Linux 5.5 (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).

(26)

(27)

About This New Release

CloudPlatform 4.2 includes more than 50 new features and enhancements. The focus of the release is on three major areas:

• Improved support for both legacy-style and cloud-style workloads

• New third-party UI plug-in architecture

• Networking enhancements

In addition to these major new areas of functionality, CloudPlatform 4.2 provides many additional enhancements in a variety of product areas. All of the new features are summarized later in this Release Note. First, here is a summary of the release as a whole.

Heterogeneous Cloud Workloads

CloudPlatform now more fully supports two different styles of workload, and you can combine both in a single cloud. In pragmatic terms, this means you can have two different styles of zone. One is a zone that follows a server virtualization model; often, this means simply putting an existing setup under CloudPlatform management. The second is a zone which is built “from the cloud up” to take advantage of cloud architecture. The hardware and software are set up differently inside each type of zone.

Third-Party UI Plugins

Customers and partners can now add capabilities to CloudPlatform. The new 3rd-party plugin architecture means that anyone can add features which will appear right alongside Citrix-developed features. The code for the plugin is simply placed in a special directory within CloudPlatform’s installed code at any time after CloudPlatform installation. The new plugin appears only when it is enabled by the cloud administrator. See Section 5.2, “Third-Party UI Plugin Framework”.

(28)

• Persistent networks without running VMs

• nTier applications

• IP addresses and networks dedicated to accounts

• IP address and IP range enhancements

• VMware vSphere Distributed Switch (VDS) support

• More types of network elements you can include in your cloud: Cisco 1000v switch and more.

See Section 5.3, “Networking Enhancements”.

Additional Enhancements

In addition to these three major new areas of functionality, CloudPlatform 4.2 includes various enhancements and new features. Some of the categories in which you will find new capabilities:

• New ways to work with VMs and hosts. See Section 5.4, “Host and Virtual Machine Enhancements”.

• New capabilities for monitoring, maintenance, and general ops. See Section 5.5, “Monitoring, Maintenance, and Operations Enhancements”.

(29)

What's New in 4.2

CloudPlatform 4.2 includes the following new features.

5.1. Features to Support Heterogeneous Workloads

The following new features help CloudPlatform 4.2 better support both legacy and cloud-era style zones.

5.1.1. Regions

To increase reliability of the cloud, you can optionally group resources into geographic regions. A region is the largest available organizational unit within a cloud deployment. A region is made up of several availability zones, where each zone is roughly equivalent to a datacenter. Each region is controlled by its own cluster of Management Servers, running in one of the zones. The zones in a region are typically located in close geographical proximity. Regions are a useful technique for providing fault tolerance and disaster recovery.

By grouping zones into regions, the cloud can achieve higher availability and scalability. User accounts can span regions, so that users can deploy VMs in multiple, widely-dispersed regions. Even if one of the regions becomes unavailable, the services are still available to the end-user through VMs deployed in another region. And by grouping communities of zones under their own nearby Management Servers, the latency of communications within the cloud is reduced compared to managing widely-dispersed zones from a single central Management Server.

Usage records can also be consolidated and tracked at the region level, creating reports or invoices for each geographic region.

(30)

5.1.2. Object Storage Plugin Architecture

Artifacts such as templates, ISOs and snapshots are kept in storage which CloudPlatform refers to as secondary storage. To improve scalability and performance, as when a number of hosts access secondary storage concurrently, object storage can be used for secondary storage. Object storage can also provide built-in high availability capability. When using object storage, access to secondary storage data can be made available across multiple zones in a region. This is a huge benefit, as it is no longer necessary to copy templates, snapshots etc. across zones as would be needed in an NFS-only environment.

Object storage itself is provided through third-party software such as Amazon Simple Storage Service (S3) or OpenStack Object Storage (Swift). These third party object storages can be integrated with CloudPlatform by writing plugin software that uses the object storage plugin capability introduced in CloudPlatform 4.2. Several new pluggable service interfaces are available so that different storage providers can develop vendor-specific plugins based on the well-defined contracts that can be seemlessly managed by CloudPlatform.

5.1.3. Zone-Wide Primary Storage Target

(Supported on KVM and VMware)

In CloudPlatform 4.2, you can provision primary storage on a per-zone basis. Data volumes in the primary storage can be attached to any VM on any host in the zone.

In previous CloudPlatform versions, each cluster had its own primary storage. Data in the primary storage was directly available only to VMs within that cluster. If a VM in a different cluster needed some of the data, it must be copied from one cluster to another, using the zone's secondary storage as an intermediate step. This operation was unnecessarily time-consuming.

5.1.4. VMware Datacenter Now Visible As a CloudPlatform Zone

In order to support zone-wide functions for VMware, changes have been made so that CloudPlatform is now aware of VMware Datacenters and can map each Datacenter to a CloudPlatform zone. Previously, CloudPlatform was only aware of VMware Clusters, a smaller organizational unit than Datacenters. This implies that a single CloudPlatform zone could possibly contain clusters from different VMware Datacenters. In order for zone-wide functions, such as zone-wide primary storage, to work for VMware hosts, CloudPlatform has to make sure that a zone contains only a single VMware Datacenter. Therefore, when you are creating a new CloudPlatform zone, you will now be able to select a VMware Datacenter for the zone. If you are provisioning multiple VMware Datacenters, each one will be set up as a single zone in CloudPlatform.

Note

If you are upgrading from a previous CloudPlatform version, and your existing deployment contains a zone with clusters from multiple VMware Datacenters, that zone will not be forcibly migrated to the new model. It will continue to function as before. However, any new zone-wide operations, such as zone-wide primary storage, will not be available in that zone.

5.2. Third-Party UI Plugin Framework

Using the new third-party plugin framework, you can write and install extensions to CloudPlatform. The installed and enabled plugins will appear in the UI alongside the Citrix-provided features.

(31)

Draft Third-Party UI Plugin Framework

The basic procedure for writing a plugin is:

1. Write the code and create the other files needed. You will need the plugin code itself (in Javascript), a thumbnail image, the plugin listing, and a CSS file.

All UI plugins have the following set of files:

+-- cloudstack/ +-- ui/ +-- plugins/

+-- csMyFirstPlugin/

+-- config.js --> Plugin metadata (title, author, vendor URL, etc.) +-- icon.png --> Icon, shown on side nav bar and plugin listing (should be square, and ~50x50px)

+-- csMyFirstPlugin.css --> CSS file, loaded automatically when plugin loads +-- csMyFirstPlugin.js --> Main JS file, containing plugin code

The same files must also be present at /tomcat/webapps/client/plugins.

2. The CloudPlatform administrator adds the folder containing your plugin code under the CloudPlatform PLUGINS folder.

(32)

3. The administrator also adds the name of your plugin to the plugin.js file in the PLUGINS folder.

4. The next time the user refreshes the UI in the browser, your plugin will appear under the Plugins button in the left navigation bar.

(33)

Draft Networking Enhancements

5.3. Networking Enhancements

The following new features provide additional networking functionality in CloudPlatform 4.2.

5.3.1. IPv6 (Technical Preview)

CloudPlatform 4.2 introduces initial support for IPv6. This feature is provided as a technical preview only. Full support is planned for a future release.

5.3.2. Portable IPs

Portable IPs in CloudPlatform are elastic IPs that can be transferred across geographically separated zones. As an administrator, you can provision a pool of portable IPs at region level and are available for user consumption. The users can acquire portable IPs if admin has provisioned portable public IPs at the region level they are part of. These IPs can be used for any service within an advanced zone. You can also use portable IPs for EIP service in Basic zones. Additionally, a portable IP can be transferred from one network to another network.

5.3.3. N-Tier Applications

In CloudPlatform 3.0.6, a functionality was added to allow users to create a multi-tier application connected to a single instance of a Virtual Router that supports inter-VLAN routing. Such a tier application is called a virtual private cloud (VPC). Users were also able to connect their multi-tier applications to a private Gateway or a Site-to-Site VPN tunnel and route certain traffic to those gateways. For CloudPlatform 4.2, additional features are implemented to enhance VPC applications.

• Internal Load Balancing between VPC tiers

• Source NAT and ACL support on private gateways

• Multiple private gateway support

• Support for ACL deny rules

• ACL support on all layer 4 protocols

• Support up to 8 VPN Gateways

• Support for blacklisting routes

• NetScaler support for VPC load balancing

• Support for KVM hypervisor

• Support for the ability to simultaneously deploy an instance on a VPC Tier and one or more Shared Networks

5.3.3.1. Adding Load Balancing Rules on a VPC

In a VPC, you can configure two types of load balancing—external LB and internal LB. External LB is nothing but a LB rule created to redirect the traffic received at a public IP of the VPC virtual router. The traffic is load balanced within a tier based on your configuration. Citrix NetScaler and VPC virtual

(34)

5.3.3.1.1. Load Balancing Within a Tier (External LB)

A CloudPlatform user or administrator may create load balancing rules that balance traffic received at a public IP to one or more VMs that belong to a network tier that provides load balancing service in a VPC. A user creates a rule, specifies an algorithm, and assigns the rule to a set of VMs within a tier.

5.3.3.1.2. Load Balancing Across Tiers

CloudPlatform supports sharing workload across different tiers within your VPC. Assume that multiple tiers are set up in your environment, such as Web tier and Application tier. Traffic to each tier is balanced on the VPC virtual router on the public side. If you want the traffic coming from the Web tier to the Application tier to be balanced, use the internal load balancing feature offered by CloudPlatform.

5.3.3.1.2.1. How Does Internal LB Work in VPC?

In this figure, a public LB rule is created for the public IP 72.52.125.10 with public port 80 and private port 81. The LB rule, created on the VPC virtual router, is applied on the traffic coming from the Internet to the VMs on the Web tier. On the Application tier two internal load balancing rules are created. An internal LB rule for the guest IP 10.10.10.4 with load balancer port 23 and instance port 25 is configured on the VM, InternalLBVM1. Another internal LB rule for the guest IP 10.10.10.4 with load balancer port 45 and instance port 46 is configured on the VM, InternalLBVM1. Another internal LB rule for the guest IP 10.10.10.6, with load balancer port 23 and instance port 25 is configured on the VM, InternalLBVM2.

5.3.3.2. Configuring Access Control List

Define Network Access Control List (ACL) on the VPC virtual router to control incoming (ingress) and outgoing (egress) traffic between the VPC tiers, and the tiers and Internet. By default, all incoming and outgoing traffic to the guest networks is blocked. To open the ports, you must create a new network ACL. The network ACLs can be created for the tiers only if the NetworkACL service is supported.

5.3.3.2.1. About Network ACL Lists

In CloudPlatform terminology, Network ACL is a group of Network ACL items. Network ACL items are nothing but numbered rules that are evaluated in order, starting with the lowest numbered rule. These rules determine whether traffic is allowed in or out of any tier associated with the network ACL. You need to add the Network ACL items to the Network ACL, then associate the Network ACL with a tier. Network ACL is associated with a VPC and can be assigned to multiple VPC tiers within a VPC. A Tier is associated with a Network ACL at all the times. Each tier can be associated with only one ACL.

The default Network ACL is used when no ACL is associated. Default behavior is all incoming traffic to guest networks is blocked and all outgoing traffic from guest networks is allowed. Default network ACL cannot be removed or modified. Contents of the default Network ACL is:

Rule Protocol Traffic type Action CIDR

1 All Ingress Deny 0.0.0.0/0

2 All Egress Deny 0.0.0.0/0

5.3.3.3. Deploying VMs to a VPC Tier and Shared Networks

CloudPlatform allows you to deploy VMs on a VPC tier and one or more shared networks. With this feature, the VMs deployed in a multi-tier application can receive monitoring services via a shared network provided by a service provider.

(35)

Draft Assigning VLANs to Isolated Networks

5.3.3.4. Adding a Private Gateway to a VPC

A private gateway can be added by the root admin only. The VPC private network has 1:1 relationship with the NIC of the physical network. You can configure multiple private gateways to a single VPC. No gateways with duplicated VLAN and IP are allowed in the same data center.

5.3.3.4.1. Source NAT on Private Gateway

You might want to deploy multiple VPCs with the same super CIDR and guest tier CIDR. Therefore, multiple guest VMs from different VPCs can have the same IPs to reach a enterprise data center through the private gateway. In such cases, a NAT service need to be configured on the private gateway. If Source NAT is enabled, the guest VMs in VPC reaches the enterprise network via private gateway IP address by using the NAT service.

The Source NAT service on a private gateway can be enabled while adding the private gateway. On deletion of a private gateway, source NAT rules specific to the private gateway are deleted.

5.3.3.4.2. ACL on Private Gateway

The traffic on the VPC private gateway is controlled by creating both ingress and egress network ACL rules. The ACLs contains both allow and deny rules. As per the rule, all the ingress traffic to the private gateway interface and all the egress traffic out from the private gateway interface are blocked. You can change this default behaviour while creating a private gateway.

5.3.3.4.3. Creating a Static Route

CloudPlatform enables you to specify routing for the VPN connection you create. You can enter one or CIDR addresses to indicate which traffic is to be routed back to the gateway.

5.3.3.4.4. Blacklisting Routes

CloudPlatform enables you to block a list of routes so that they are not assigned to any of the VPC private gateways. Specify the list of routes that you want to blacklist in the blacklisted.routes global parameter. Note that the parameter update affects only new static route creations. If you block an existing static route, it remains intact and continue functioning. You cannot add a static route if the route is blacklisted for the zone.

5.3.4. Assigning VLANs to Isolated Networks

CloudPlatform provides you the ability to control VLAN assignment to Isolated networks. You can assign a VLAN ID when a network is created, just the way it's done for Shared networks.

The former behaviour also is supported — VLAN is randomly allocated to a network from the VNET range of the physical network when the network turns to Implemented state. The VLAN is released back to the VNET pool when the network shuts down as a part of the Network Garbage Collection. The VLAN can be re-used either by the same network when it is implemented again, or by any other network. On each subsequent implementation of a network, a new VLAN can be assigned.

Note

(36)

5.3.5. Persistent Networks

The network that you can provision without having to deploy any VMs on it is called a persistent network. A persistent network can be part of a VPC or a non-VPC environment.

When you create other types of network, a network is only a database entry until the first VM is created on that network. When the first VM is created, a VLAN ID is assigned and the network is provisioned. Also, when the last VM is destroyed, the VLAN ID is released and the network is no longer available. With the addition of persistent network, you will have the ability to create a network in CloudPlatform in which physical devices can be deployed without having to run any VMs. Additionally, you can deploy physical devices on that network.

One of the advantages of having a persistent network is that you can create a VPC with a tier consisting of only physical devices. For example, you might create a VPC for a three-tier application, deploy VMs for Web and Application tier, and use physical machines for the Database tier. Another use case is that if you are providing services by using physical hardware, you can define the network as persistent and therefore even if all its VMs are destroyed the services will not be discontinued.

• Persistent network is designed for isolated networks.

• All default network offerings are non-persistent.

• A network offering cannot be editable because changing it affects the behavior of the existing networks that were created using this network offering.

• When you create a guest network, the network offering that you select defines the network

persistence. This in turn depends on whether persistent network is enabled in the selected network offering.

• An existing network can be made persistent by changing its network offering to an offering that has the Persistent option enabled. While setting this property, even if the network has no running VMs, the network is provisioned.

• An existing network can be made non-persistent by changing its network offering to an offering that has the Persistent option disabled. If the network has no running VMs, during the next network garbage collection run the network is shut down.

• When the last VM on a network is destroyed, the network garbage collector checks if the network offering associated with the network is persistent, and shuts down the network only if it is non-persistent.

5.3.6. Cisco VNMC Support

Cisco Virtual Network Management Center (VNMC) provides centralized multi-device and policy management for Cisco Network Virtual Services. When Cisco VNMC is integrated with ASA 1000v Cloud Firewall and Cisco Nexus 1000v dvSwitch in CloudPlatform you will be able to:

• Configure Cisco ASA 1000v Firewalls

• Create and apply security profiles that contain ACL policy sets for both ingress and egress traffic, and NAT policy sets

(37)

Draft VMware vNetwork Distributed vSwitch

5.3.7. VMware vNetwork Distributed vSwitch

CloudPlatform supports VMware vSphere Distributed Switch (VDS) for virtual network configuration in a VMware vSphere environment. Each vCenter server instance can support up to 128 VDSs and each VDS can manage up to 500 VMware hosts.

5.3.7.1. About VMware Distributed Virtual Switch

VMware VDS is an aggregation of host-level virtual switches on a VMware vCenter server. VDS abstracts the configuration of individual virtual switches that span across a large number of hosts, and enables centralized provisioning, administration, and monitoring for your entire datacenter from a centralized interface. VDS is controlled as a single distributed switch at the datacenter level. So there needed a component to ensure that the network configurations on the source and the destination virtual switch are consistent and will allow the VM to operate without breaking connectivity or network policies. Particularly during migration of VM across hosts, the sync up among peers need to be taken care. However in case of distributed vSwitch during VMotion, the vCenter server, would update the vSwitch modules on the hosts in cluster accordingly.

5.3.7.2. Enabling Virtual Distributed Switch in CloudPlatform

To make a CloudPlatform deployment VDS enabled, set the vmware.use.dvswitch parameter to true by using the Global Settings page in the CloudPlatform UI and restart the Management Server. Unless you enable the vmware.use.dvswitch parameter, you cannot see any UI options specific to VDS, and CloudPlatform ignores the VDS-specific parameters specified in the AddCluster API call. Additionally, CloudPlatform uses VDS for virtual network infrastructure if the value of vmware.use.dvswitch parameter is true and the value of vmware.use.nexus.dvswitch parameter is false.

CloudPlatform supports configuring virtual networks in a deployment with a mix of Virtual Distributed Switch, Standard Virtual Switch and Nexus 1000v Virtual Switch.

5.3.8. IP Reservation in Isolated Guest Networks

In isolated guest networks, a part of the guest IP address space can be reserved for

non-CloudPlatform VMs or physical servers. To do so, you configure a range of Reserved IP addresses by specifying the CIDR when a guest network is in Implemented state. If your customers wish to have non-CloudPlatform controlled VMs or physical servers on the same network, they can share a part of the IP address space that is primarily provided to the guest network.

In an Advanced zone, an IP address range or a CIDR is assigned to a network when the network is defined. The CloudPlatform virtual router acts as the DHCP server and uses CIDR for assigning IP addresses to the guest VMs. If you decide to reserve IP ranges for non-CloudPlatform purposes, you can specify a part of the IP address range or the CIDR that should only be allocated by the DHCP service of the virtual router to the guest VMs created in CloudPlatform. The remaining IPs in that network are called Reserved IP Range. When IP reservation is configured, the administrator can add additional VMs or physical servers that are not part of CloudPlatform to the same network and assign them the Reserved IP addresses. CloudPlatform guest VMs cannot acquire IPs from the Reserved IP Range. Consider the following before you reserve an IP range for non-CloudPlatform machines:

• IP Reservation can be applied only when the network is in Implemented state.

(38)

You cannot apply IP Reservation if any VM is alloted with an IP address that is outside the Guest VM CIDR.

• To reset an existing IP Reservation, apply IP reservation by specifying the value of network CIDR in the CIDR field.

For example, the following table describes three scenarios of guest network creation:

Case CIDR Network CIDR Reserved IP

Range for Non-CloudPlatform VMs

Description

1 10.1.1.0/24 None None No IP

Reservation. 2 10.1.1.0/26 10.1.1.0/24 10.1.1.64 to

10.1.1.254

IP Reservation configured by the UpdateNetwork API with

guestvmcidr=10.1.1.0/26 or enter

10.1.1.0/26 in the CIDR field in the UI.

3 10.1.1.0/24 None None Removing IP

Reservation by the UpdateNetwork API with guestvmcidr=10.1.1.0/24 or enter

10.1.1.0/24 in the CIDR field in the UI.

• The IP Reservation is not supported if active IPs that are found outside the Guest VM CIDR.

• Upgrading network offering which causes a change in CIDR (such as upgrading an offering with no external devices to one with external devices) IP Reservation becomes void if any. Reconfigure IP Reservation in the new re-implemeted network.

5.3.9. Dedicated Resources: Public IP Addresses and VLANs Per

Account

CloudPlatform provides you the ability to reserve a set of public IP addresses and VLANs exclusively for an account. During zone creation, you can continue to define a set of VLANs and multiple public IP ranges. This feature extends the functionality to enable you to dedicate a fixed set of VLANs and guest IP addresses for a tenant.

This feature provides you the following capabilities:

• Reserve a VLAN range and public IP address range from an Advanced zone and assign it to an account

(39)

Draft Egress Firewall Rules

• Disassociate a VLAN and public IP address range from an account

Note

Ensure that you check whether the required range is available and conforms to account limits. The maximum IPs per account limit cannot be superseded.

5.3.10. Egress Firewall Rules

Egress firewall rules were previously supported on virtual routers, and now they are also supported on Juniper SRX external networking devices.

Egress traffic originates from a private network to a public network, such as the Internet. By default, the egress traffic is blocked, so no outgoing traffic is allowed from a guest network to the Internet. However, you can control the egress traffic in an Advanced zone by creating egress firewall rules. When an egress firewall rule is applied, the traffic specific to the rule is allowed and the remaining traffic is blocked. When all the firewall rules are removed the default policy, Block, is applied.

Note

Egress firewall rules are not supported on shared networks. They are supported only on isolated guest networks.

Consider the following scenarios to apply egress firewall rules:

• Allow egress traffic from a specified source CIDR. The Source CIDR is part of the guest network CIDR.

• Allow egress traffic with a given destination protocol: TCP, UDP, ICMP, or ALL.

• Allow egress traffic with a particular destination protocol and port range. The start and end port is specified for TCP or UDP. For ICMP, a type and code are specified.

5.3.11. Non-Contiguous VLAN Ranges

CloudPlatform provides you with the flexibility to add non contiguous VLAN ranges to your network. The administrator can either update an existing VLAN range or add multiple non contiguous VLAN ranges while creating a zone. You can also use the UpdatephysicalNetwork API to extend the VLAN range.

5.3.12. Isolation in Advanced Zone Using Private VLAN

Isolation of guest traffic in shared networks can be achieved by using Private VLANs (PVLAN). PVLANs provide Layer 2 isolation between ports within the same VLAN. In a PVLAN-enabled shared network, a user VM cannot reach other user VM though they can reach the DHCP server and gateway, this would in turn allow users to control traffic within a network and help them deploy multiple applications without communication between application as well as prevent communication with other users’ VMs.

(40)

• Supported on KVM, XenServer, and VMware hypervisors

• PVLAN-enabled shared network can be a part of multiple networks of a guest VM.

For further reading:

• Understanding Private VLANs1

• Cisco Systems' Private VLANs: Scalable Security in a Multi-Client Environment2

• Private VLAN (PVLAN) on vNetwork Distributed Switch - Concept Overview (1010691)3

5.3.13. Configuring Multiple IP Addresses on a Single NIC

CloudPlatform now provides you the ability to associate multiple private IP addresses per guest VM NIC. This feature is supported on all the network configurations—Basic, Advanced, and VPC. Security Groups, Static NAT and Port forwarding services are supported on these additional IPs. In addition to the primary IP, you can assign additional IPs to the guest VM NIC. Up to 256 IP addresses are allowed per NIC.

As always, you can specify an IP from the guest subnet; if not specified, an IP is automatically picked up from the guest VM subnet. You can view the IPs associated with for each guest VM NICs on the UI. You can apply NAT on these additional guest IPs by using firewall configuration in the CloudPlatform UI. You must specify the NIC to which the IP should be associated.

This feature is supported on XenServer, KVM, and VMware hypervisors.

Some of the use cases are described below:

5.3.14. Adding Multiple IP Ranges

Note

The feature can only be implemented on IPv4 addresses.

CloudPlatform provides you with the flexibility to add guest IP ranges from different subnets in Basic zones and security groups-enabled Advanced zones. For security groups-enabled Advanced zones, it implies multiple subnets can be added to the same VLAN. With the addition of this feature, you will be able to add IP address ranges from the same subnet or from a different one when IP address are exhausted. This would in turn allows you to employ higher number of subnets and thus reduce the address management overhead.

Ensure that you manually configure the gateway of the new subnet before adding the IP range. Note that CloudPlatform supports only one gateway for a subnet; overlapping subnets are not currently supported.

1

http://www.cisco.com/en/US/docs/switches/lan/catalyst3750/software/release/12.2_25_see/configuration/guide/ swpvlan.html#wp1038379

2

(41)

Draft Reconfiguring Networks in VMs

You can also delete IP ranges. This operation fails if an IP from the remove range is in use. If the remove range contains the IP address on which the DHCP server is running, CloudPlatform acquires a new IP from the same subnet. If no IP is available in the subnet, the remove operation fails.

This feature is supported on KVM, xenServer, and VMware hypervisors.

5.3.15. Reconfiguring Networks in VMs

CloudPlatform provides you the ability to move VMs between networks and reconfigure a VM's network. You can remove a VM from a network and add to a new network. You can also change the default network of a virtual machine. With this functionality, hybrid or traditional server loads can be accommodated with ease.

This feature is supported on XenServer and KVM hypervisors.

For adding or removing a NIC to work, ensure that vm-tools are running on guest VMs on VMware host.

5.3.16. Global Server Load Balancing

CloudPlatform supports Global Server Load Balancing (GSLB) functionalities to provide business continuity by load balancing traffic to an instance on active zones only in case of zone failures . CloudPlatform achieve this by extending its functionality of integrating with NetScaler Application Delivery Controller (ADC), which also provides various GSLB capabilities, such as disaster recovery and load balancing. The DNS redirection technique is used to achieve GSLB in CloudPlatform. In order to support this functionality, region level services and service provider are introduced. A new service 'GSLB' is introduced as a region level service. The GSLB service provider is introduced that will provider the GSLB service. Currently, NetScaler is the supported GSLB provider in CloudPlatform. GSLB functionality works in an Active-Active data center environment.

5.4. Host and Virtual Machine Enhancements

The following new features expand the ways you can use hosts and virtual machines.

5.4.1. VMware DRS Support

The VMware vSphere Distributed Resources Scheduler (DRS) is supported.

5.4.2. Windows 8 and Windows Server as VM Guest OS

Supported on XenServer, VMware, and KVM.

Windows 8 and Windows Server 2012 can now be used as OS types on guest virtual machines. The OS would be made available the same as any other, by uploading an ISO or a template. The instructions for uploading ISOs and templates are given in the Administrator's Guide.