CloudPlatform
(powered by Apache
CloudStack) Version 4.2
Administrator's Guide
Revised October 27, 2013 10:50 pm Pacific
Citrix CloudPlatform
CloudPlatform (powered by Apache CloudStack) Version 4.2 Administrator's Guide
CloudPlatform (powered by Apache CloudStack) Version 4.2
Administrator's Guide
Revised October 27, 2013 10:50 pm Pacific
Author Citrix CloudPlatform
© 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.
If you have already installed CloudPlatform or you want to learn more about the ongoing operation and
maintenance of a CloudPlatform-powered cloud, read this documentation. It will help you start using,
configuring, and managing the ongoing operation of your cloud.
1. Getting More Information and Help 1
1.1. Additional Documentation Available ............................................................................... 1
1.2. Citrix Knowledge Center ............................................................................................... 1
1.3. Contacting Support ....................................................................................................... 1
2. Concepts 3
2.1. What Is CloudPlatform? ................................................................................................ 3
2.2. What Can CloudPlatform Do? ....................................................................................... 3
2.3. Deployment Architecture Overview ................................................................................ 4
2.3.1. Management Server Overview ........................................................................... 5
2.3.2. Cloud Infrastructure Overview ............................................................................ 5
2.3.3. Networking Overview ......................................................................................... 6
3. Cloud Infrastructure Concepts 9
3.1. About Regions ............................................................................................................. 9
3.2. About Zones ................................................................................................................ 9
3.3. About Pods ................................................................................................................ 11
3.4. About Clusters ........................................................................................................... 12
3.5. About Hosts ............................................................................................................... 13
3.6. About Primary Storage ............................................................................................... 13
3.7. About Secondary Storage ........................................................................................... 14
3.8. About Physical Networks ............................................................................................ 14
3.8.1. Basic Zone Network Traffic Types .................................................................... 15
3.8.2. Basic Zone Guest IP Addresses ....................................................................... 16
3.8.3. Advanced Zone Network Traffic Types .............................................................. 16
3.8.4. Advanced Zone Guest IP Addresses ................................................................ 16
3.8.5. Advanced Zone Public IP Addresses ................................................................ 17
3.8.6. System Reserved IP Addresses ....................................................................... 17
4. Accounts 19
4.1. Accounts, Users, and Domains ................................................................................... 19
4.1.1. Dedicating Resources to Accounts and Domains ............................................... 20
4.2. Using an LDAP Server for User Authentication ............................................................ 21
4.2.1. Configuring an LDAP Server ............................................................................ 21
4.2.2. Example LDAP Configuration Commands ......................................................... 23
4.2.3. Search Base ................................................................................................... 23
4.2.4. Query Filter ..................................................................................................... 24
4.2.5. Search User Bind DN ...................................................................................... 25
4.2.6. SSL Keystore Path and Password .................................................................... 25
5. User Services Overview 27
5.1. Service Offerings, Disk Offerings, Network Offerings, and Templates ............................. 27
6. User Interface 29
6.1. Supported Browsers ................................................................................................... 29
6.2. Log In to the UI ......................................................................................................... 29
6.2.1. End User's UI Overview ................................................................................... 29
6.2.2. Root Administrator's UI Overview ..................................................................... 30
6.2.3. Logging In as the Root Administrator ................................................................ 30
6.2.4. Changing the Root Password ........................................................................... 31
6.3. Using SSH Keys for Authentication ............................................................................. 31
6.3.1. Creating an Instance from a Template that Supports SSH Keys .......................... 31
6.3.2. Creating the SSH Keypair ................................................................................ 32
6.3.3. Creating an Instance ........................................................................................ 33
6.3.4. Logging In Using the SSH Keypair ................................................................... 33
6.3.5. Resetting SSH Keys ........................................................................................ 33
iii
CloudPlatform (powered by Apache CloudStack) Version 4.2 Administrator's Guide
7. Using Projects to Organize Users and Resources 35
7.1. Overview of Projects .................................................................................................. 35
7.2. Configuring Projects ................................................................................................... 35
7.2.1. Setting Up Invitations ....................................................................................... 35
7.2.2. Setting Resource Limits for Projects ................................................................. 36
7.2.3. Setting Project Creator Permissions .................................................................. 36
7.3. Creating a New Project .............................................................................................. 37
7.4. Adding Members to a Project ...................................................................................... 37
7.4.1. Sending Project Membership Invitations ............................................................ 37
7.4.2. Adding Project Members From the UI ............................................................... 38
7.5. Accepting a Membership Invitation .............................................................................. 38
7.6. Suspending or Deleting a Project ................................................................................ 39
7.7. Using the Project View ............................................................................................... 39
8. Steps to Provisioning Your Cloud Infrastructure 41
8.1. Overview of Provisioning Steps ................................................................................... 41
8.2. Adding Regions (optional) ........................................................................................... 42
8.2.1. The First Region: The Default Region ............................................................... 42
8.2.2. Adding a Region .............................................................................................. 42
8.2.3. Adding Third and Subsequent Regions ............................................................. 43
8.2.4. Deleting a Region ............................................................................................ 44
8.3. Adding a Zone ........................................................................................................... 45
8.3.1. Create a Secondary Storage Mount Point for the New Zone ............................... 45
8.3.2. Prepare the System VM Template .................................................................... 45
8.3.3. Steps to Add a New Zone ................................................................................ 46
8.4. Adding a Pod ............................................................................................................. 55
8.5. Adding a Cluster ........................................................................................................ 56
8.5.1. Add Cluster: KVM or XenServer ....................................................................... 56
8.5.2. Add Cluster: OVM ........................................................................................... 56
8.5.3. Add Cluster: vSphere ....................................................................................... 57
8.6. Adding a Host ............................................................................................................ 60
8.6.1. Adding a Host (XenServer, KVM, or OVM) ........................................................ 60
8.6.2. Adding a Host (vSphere) .................................................................................. 62
8.7. Adding Primary Storage .............................................................................................. 62
8.8. Adding Secondary Storage ......................................................................................... 63
8.8.1. Adding an NFS Secondary Staging Store for Each Zone .................................... 64
8.9. Initialize and Test ....................................................................................................... 65
9. Service Offerings 67
9.1. Compute and Disk Service Offerings ........................................................................... 67
9.1.1. Creating a New Compute Offering .................................................................... 67
9.1.2. Creating a New Disk Offering ........................................................................... 68
9.1.3. Modifying or Deleting a Service Offering ........................................................... 69
9.2. System Service Offerings ........................................................................................... 69
9.2.1. Creating a New System Service Offering .......................................................... 69
9.2.2. Changing the Secondary Storage VM Service Offering on a Guest Network ......... 70
10. Setting Up Networking for Users 73
10.1. Overview of Setting Up Networking for Users ............................................................. 73
10.2. About Virtual Networks ............................................................................................. 73
10.2.1. Isolated Networks .......................................................................................... 73
10.2.2. Shared Networks ........................................................................................... 73
10.2.3. Runtime Allocation of Virtual Network Resources ............................................. 74
10.3. Network Service Providers ........................................................................................ 74
10.4. Network Service Providers Support Matrix ................................................................. 74
iv
10.4.1. Individual ....................................................................................................... 74
10.4.2. Support Matrix for an Isolated Network (Combination) ...................................... 75
10.4.3. Support Matrix for Shared Network (Combination) ............................................ 76
10.4.4. Support Matrix for Basic Zone ........................................................................ 77
10.5. Network Offerings ..................................................................................................... 77
10.5.1. Creating a New Network Offering ................................................................... 78
10.5.2. Changing the Network Offering on a Guest Network ........................................ 81
10.5.3. Creating and Changing a Virtual Router Network Offering ................................. 82
11. Working With Virtual Machines 85
11.1. About Working with Virtual Machines ......................................................................... 85
11.2. Best Practices for Virtual Machines ........................................................................... 85
11.2.1. Monitor VMs for Max Capacity ........................................................................ 86
11.2.2. Install Required Tools and Drivers .................................................................. 86
11.3. VM Lifecycle ............................................................................................................ 86
11.4. Creating VMs ........................................................................................................... 87
11.4.1. Creating a VM from a template ....................................................................... 87
11.4.2. Creating a VM from an ISO ............................................................................ 88
11.4.3. Configuring Usage of Linked Clones on VMware ............................................. 88
11.5. Accessing VMs ......................................................................................................... 89
11.6. Appending a Display Name to the Guest VM’s Internal Name ...................................... 89
11.7. Stopping and Starting VMs ....................................................................................... 90
11.8. Assigning VMs to Hosts ............................................................................................ 90
11.8.1. Affinity Groups ............................................................................................... 91
11.9. Virtual Machine Snapshots for VMware ...................................................................... 92
11.9.1. Limitations on VM Snapshots ......................................................................... 93
11.9.2. Configuring VM Snapshots ............................................................................. 93
11.9.3. Using VM Snapshots ..................................................................................... 93
11.10. Changing the VM Name, OS, or Group .................................................................... 94
11.11. Changing the Service Offering for a VM ................................................................... 95
11.11.1. CPU and Memory Scaling for Running VMs .................................................. 95
11.11.2. Updating Existing VMs ................................................................................. 96
11.11.3. Configuring Dynamic CPU and RAM Scaling ................................................. 96
11.11.4. How to Dynamically Scale CPU and RAM ..................................................... 96
11.11.5. Limitations ................................................................................................... 96
11.12. Resetting the Virtual Machine Root Volume on Reboot ............................................. 97
11.13. Moving VMs Between Hosts (Manual Live Migration) ................................................ 97
11.14. Deleting VMs .......................................................................................................... 98
11.15. Recovering a Destroyed VM .................................................................................... 98
11.16. Working with ISOs .................................................................................................. 98
11.16.1. Adding an ISO ............................................................................................. 99
11.16.2. Attaching an ISO to a VM ........................................................................... 100
11.16.3. Changing a VM's Base Image ..................................................................... 100
12. Working With Hosts 103
12.1. Adding Hosts .......................................................................................................... 103
12.2. Scheduled Maintenance and Maintenance Mode for Hosts ........................................ 103
12.2.1. vCenter and Maintenance Mode ................................................................... 103
12.2.2. XenServer and Maintenance Mode ............................................................... 103
12.3. Disabling and Enabling Zones, Pods, and Clusters ................................................... 104
12.4. Removing Hosts ..................................................................................................... 104
12.4.1. Removing XenServer and KVM Hosts ........................................................... 105
12.4.2. Removing vSphere Hosts ............................................................................. 105
12.5. Re-Installing Hosts .................................................................................................. 105
12.6. Maintaining Hypervisors on Hosts ............................................................................ 105
v
CloudPlatform (powered by Apache CloudStack) Version 4.2 Administrator's Guide
12.7. Using Cisco UCS as Bare Metal Host CloudPlatform ................................................ 105
12.7.1. Registering a UCS Manager ......................................................................... 106
12.7.2. Associating a Profile with a UCS Blade ......................................................... 106
12.7.3. Disassociating a Profile from a UCS Blade .................................................... 107
12.8. Changing Host Password ........................................................................................ 107
12.9. Over-Provisioning and Service Offering Limits .......................................................... 108
12.9.1. Limitations on Over-Provisioning in XenServer and KVM ................................ 109
12.9.2. Requirements for Over-Provisioning .............................................................. 109
12.9.3. Setting Over-Provisioning Ratios ................................................................... 109
12.9.4. Service Offering Limits and Over-Provisioning ................................................ 110
12.10. VLAN Provisioning ................................................................................................ 110
12.10.1. VLAN Allocation Example ........................................................................... 111
12.10.2. Adding Non Contiguous VLAN Ranges ........................................................ 111
12.10.3. Assigning VLANs to Isolated Networks ........................................................ 112
13. Working with Templates 113
13.1. Creating Templates: Overview ................................................................................. 113
13.2. Requirements for Templates ................................................................................... 113
13.3. Best Practices for Templates ................................................................................... 113
13.4. The Default Template ............................................................................................. 113
13.5. Private and Public Templates .................................................................................. 114
13.6. Creating a Template from an Existing Virtual Machine .............................................. 114
13.7. Creating a Template from a Snapshot ..................................................................... 115
13.8. Uploading Templates .............................................................................................. 115
13.9. Exporting Templates ............................................................................................... 117
13.10. Creating a Windows Template ............................................................................... 117
13.10.1. System Preparation for Windows Server 2008 R2 ........................................ 117
13.10.2. System Preparation for Windows Server 2003 R2 ........................................ 121
13.11. Importing Amazon Machine Images ....................................................................... 122
13.12. Converting a Hyper-V VM to a Template ................................................................ 125
13.13. Adding Password Management to Your Templates ................................................. 126
13.13.1. Linux OS Installation .................................................................................. 127
13.13.2. Windows OS Installation ............................................................................. 127
13.14. Deleting Templates ............................................................................................... 127
14. Working With Storage 129
14.1. Storage Overview ................................................................................................... 129
14.2. Primary Storage ..................................................................................................... 129
14.2.1. Best Practices for Primary Storage ............................................................... 129
14.2.2. Runtime Behavior of Primary Storage ........................................................... 129
14.2.3. Hypervisor Support for Primary Storage ........................................................ 129
14.2.4. Storage Tags ............................................................................................... 130
14.2.5. Maintenance Mode for Primary Storage ......................................................... 131
14.3. Secondary Storage ................................................................................................. 131
14.3.1. Best Practices for Secondary Storage ........................................................... 131
14.3.2. Changing the Secondary Storage IP Address ................................................ 131
14.3.3. Changing Secondary Storage Servers ........................................................... 132
14.4. Working With Volumes ............................................................................................ 132
14.4.1. Creating a New Volume ............................................................................... 132
14.4.2. Uploading an Existing Volume to a Virtual Machine ........................................ 133
14.4.3. Attaching a Volume ...................................................................................... 134
14.4.4. Detaching and Moving Volumes .................................................................... 135
14.4.5. VM Storage Migration .................................................................................. 135
14.4.6. Resizing Volumes ........................................................................................ 137
14.4.7. Reset VM to New Root Disk on Reboot ......................................................... 138
vi
14.4.8. Volume Deletion and Garbage Collection ...................................................... 138
14.5. Working with Snapshots .......................................................................................... 138
14.5.1. Automatic Snapshot Creation and Retention .................................................. 139
14.5.2. Incremental Snapshots and Backup .............................................................. 139
14.5.3. Volume Status ............................................................................................. 139
14.5.4. Snapshot Restore ........................................................................................ 140
14.5.5. Snapshot Job Throttling ................................................................................ 140
14.5.6. VMware Volume Snapshot Performance ........................................................ 140
15. Working with Usage 141
15.1. Configuring the Usage Server ................................................................................. 141
15.2. Setting Usage Limits ............................................................................................... 143
15.2.1. Globally Configured Limits ............................................................................ 144
15.2.2. Default Account Resource Limits .................................................................. 145
15.2.3. Per-Domain Limits ....................................................................................... 146
16. Managing Networks and Traffic 147
16.1. Guest Traffic .......................................................................................................... 147
16.2. Networking in a Pod ............................................................................................... 147
16.3. Networking in a Zone .............................................................................................. 148
16.4. Basic Zone Physical Network Configuration .............................................................. 149
16.5. Advanced Zone Physical Network Configuration ....................................................... 149
16.5.1. Configuring Isolated Guest Network .............................................................. 149
16.5.2. Configure Public Traffic in an Advanced Zone ................................................ 150
16.5.3. Configuring a Shared Guest Network ............................................................ 151
16.6. Using Security Groups to Control Traffic to VMs ....................................................... 152
16.6.1. About Security Groups ................................................................................. 152
16.6.2. Security Groups in Advanced Zones (KVM Only) ........................................... 152
16.6.3. Enabling Security Groups ............................................................................. 153
16.6.4. Adding a Security Group .............................................................................. 153
16.6.5. Adding Ingress and Egress Rules to a Security Group .................................... 153
16.7. External Firewalls and Load Balancers .................................................................... 154
16.7.1. About Using a NetScaler Load Balancer ........................................................ 155
16.7.2. Configuring SNMPCommunity String on a RHEL Server ................................. 156
16.7.3. Initial Setup of External Firewalls and Load Balancers .................................... 157
16.7.4. Ongoing Configuration of External Firewalls and Load Balancers ..................... 158
16.8. Load Balancer Rules .............................................................................................. 158
16.8.1. Adding a Load Balancer Rule ....................................................................... 158
16.8.2. Configuring AutoScale .................................................................................. 159
16.8.3. Sticky Session Policies for Load Balancer Rules ............................................ 164
16.8.4. Health Checks for Load Balancer Rules ........................................................ 164
16.9. Global Server Load Balancing ................................................................................. 165
16.9.1. About Global Server Load Balancing ............................................................. 165
16.9.2. Configuring GSLB ........................................................................................ 167
16.10. Using Multiple Guest Networks .............................................................................. 172
16.10.1. Adding an Additional Guest Network ........................................................... 172
16.10.2. Reconfiguring Networks in VMs .................................................................. 172
16.11. Guest IP Ranges .................................................................................................. 174
16.12. Acquiring a New IP Address .................................................................................. 174
16.13. Releasing an IP Address ....................................................................................... 174
16.14. Reserving Public IP Addresses and VLANs for Accounts ......................................... 175
16.14.1. Dedicating IP Address Ranges to an Account .............................................. 175
16.14.2. Dedicating VLAN Ranges to an Account ...................................................... 176
16.15. IP Reservation in Isolated Guest Networks ............................................................. 177
16.15.1. IP Reservation Considerations .................................................................... 177
vii
CloudPlatform (powered by Apache CloudStack) Version 4.2 Administrator's Guide
16.15.2. Limitations ................................................................................................. 178
16.15.3. Best Practices ............................................................................................ 178
16.15.4. Reserving an IP Range .............................................................................. 178
16.16. Configuring Multiple IP Addresses on a Single NIC ................................................. 178
16.16.1. Use Cases ................................................................................................. 179
16.16.2. Guidelines ................................................................................................. 179
16.16.3. Assigning Additional IPs to a VM ................................................................ 179
16.16.4. Port Forwarding and StaticNAT Services Changes ....................................... 179
16.17. Multiple Subnets in Shared Network ...................................................................... 180
16.17.1. Prerequisites and Guidelines ...................................................................... 180
16.17.2. Adding Multiple Subnets to a Shared Network .............................................. 180
16.18. About Elastic IP .................................................................................................... 181
16.19. Portable IPs ......................................................................................................... 183
16.19.1. About Portable IP ....................................................................................... 183
16.19.2. Configuring Portable IPs ............................................................................. 184
16.19.3. Acquiring a Portable IP ............................................................................... 184
16.19.4. Transferring Portable IP .............................................................................. 185
16.20. Static NAT ............................................................................................................ 185
16.20.1. Enabling or Disabling Static NAT ................................................................ 185
16.21. IP Forwarding and Firewalling ............................................................................... 186
16.21.1. Egress Firewall Rules in an Advanced Zone ................................................ 186
16.21.2. Firewall Rules ............................................................................................ 188
16.21.3. Port Forwarding ......................................................................................... 189
16.22. IP Load Balancing ................................................................................................ 189
16.23. DNS and DHCP ................................................................................................... 190
16.24. Remote Access VPN ............................................................................................ 190
16.24.1. Configuring Remote Access VPN ................................................................ 190
16.24.2. Using Remote Access VPN with Windows ................................................... 191
16.24.3. Using Remote Access VPN with Mac OS X ................................................. 192
16.24.4. Setting Up a Site-to-Site VPN Connection .................................................... 192
16.25. Isolation in Advanced Zone Using Private VLAN ..................................................... 200
16.25.1. About Private VLAN ................................................................................... 200
16.25.2. Prerequisites .............................................................................................. 201
16.25.3. Creating a PVLAN-Enabled Guest Network .................................................. 201
16.26. About Inter-VLAN Routing ..................................................................................... 202
16.27. Configuring a Virtual Private Cloud ........................................................................ 204
16.27.1. About Virtual Private Clouds ....................................................................... 204
16.27.2. Adding a Virtual Private Cloud .................................................................... 206
16.27.3. Adding Tiers .............................................................................................. 207
16.27.4. Configuring Network Access Control List ..................................................... 209
16.27.5. Adding a Private Gateway to a VPC ............................................................ 212
16.27.6. Deploying VMs to the Tier .......................................................................... 215
16.27.7. Deploying VMs to VPC Tier and Shared Networks ....................................... 215
16.27.8. Acquiring a New IP Address for a VPC ....................................................... 216
16.27.9. Releasing an IP Address Alloted to a VPC .................................................. 217
16.27.10. Enabling or Disabling Static NAT on a VPC ............................................... 218
16.27.11. Adding Load Balancing Rules on a VPC .................................................... 219
16.27.12. Adding a Port Forwarding Rule on a VPC .................................................. 225
16.27.13. Removing Tiers ........................................................................................ 226
16.27.14. Editing, Restarting, and Removing a Virtual Private Cloud ........................... 227
16.28. Persistent Networks .............................................................................................. 227
16.28.1. Persistent Network Considerations .............................................................. 227
16.28.2. Creating a Persistent Guest Network ........................................................... 228
viii
17. Working with System Virtual Machines 229
17.1. The System VM Template ....................................................................................... 229
17.2. Multiple System VM Support for VMware ................................................................. 229
17.3. Console Proxy ........................................................................................................ 229
17.3.1. Changing the Console Proxy SSL Certificate and Domain ............................... 230
17.4. Virtual Router ......................................................................................................... 231
17.4.1. Configuring the Virtual Router ....................................................................... 231
17.4.2. Upgrading a Virtual Router with System Service Offerings .............................. 232
17.4.3. Best Practices for Virtual Routers ................................................................. 232
17.5. Secondary Storage VM ........................................................................................... 232
18. System Reliability and High Availability 233
18.1. HA for Management Server ..................................................................................... 233
18.2. HA-Enabled Virtual Machines .................................................................................. 233
18.3. Dedicated HA Hosts ............................................................................................... 233
18.4. Primary Storage Outage and Data Loss ................................................................... 234
18.5. Secondary Storage Outage and Data Loss .............................................................. 234
18.6. Limiting the Rate of API Requests ........................................................................... 234
18.6.1. Configuring the API Request Rate ................................................................ 234
18.6.2. Limitations on API Throttling ......................................................................... 235
19. Managing the Cloud 237
19.1. Using Tags to Organize Resources in the Cloud ....................................................... 237
19.2. Setting Configuration Parameters ............................................................................ 238
19.2.1. About Configuration Parameters ................................................................... 238
19.2.2. Setting Global Configuration Parameters ....................................................... 239
19.2.3. Setting Local Configuration Parameters ......................................................... 239
19.2.4. Granular Global Configuration Parameters ..................................................... 240
19.3. Changing the Database Configuration ...................................................................... 242
19.4. Administrator Alerts ................................................................................................. 242
19.4.1. Customizing Alerts with Global Configuration Settings .................................... 243
19.4.2. Sending Alerts to External SNMP and Syslog Managers ................................. 243
19.5. Customizing the Network Domain Name .................................................................. 245
19.6. Stopping and Restarting the Management Server ..................................................... 246
20. CloudPlatform API 247
20.1. Provisioning and Authentication API ........................................................................ 247
20.2. Allocators ............................................................................................................... 247
20.3. User Data and Meta Data ....................................................................................... 247
21. Tuning 249
21.1. Performance Monitoring .......................................................................................... 249
21.2. Increase Management Server Maximum Memory ..................................................... 249
21.3. Set Database Buffer Pool Size ................................................................................ 249
21.4. Set and Monitor Total VM Limits per Host ................................................................ 250
21.5. Configure XenServer dom0 Memory ........................................................................ 250
22. Troubleshooting 251
22.1. Events .................................................................................................................... 251
22.1.1. Event Logs .................................................................................................. 251
22.1.2. Event Notification ......................................................................................... 251
22.1.3. Standard Events .......................................................................................... 252
22.1.4. Long Running Job Events ............................................................................ 252
22.1.5. Event Log Queries ....................................................................................... 253
22.1.6. Deleting and Archiving Events and Alerts ...................................................... 253
22.2. Working with Server Logs ....................................................................................... 254
ix
CloudPlatform (powered by Apache CloudStack) Version 4.2 Administrator's Guide
22.3. Log Collection Utility cloud-bugtool .......................................................................... 255
22.3.1. Using cloud-bugtool ..................................................................................... 255
22.4. Data Loss on Exported Primary Storage .................................................................. 255
22.5. Recovering a Lost Virtual Router ............................................................................. 256
22.6. Maintenance mode not working on vCenter .............................................................. 256
22.7. Unable to deploy VMs from uploaded vSphere template ............................................ 257
22.8. Unable to power on virtual machine on VMware ....................................................... 257
22.9. Load balancer rules fail after changing network offering ............................................ 258
A. Event Types 259
B. Alerts 261
x
Chapter 1.
Getting More Information and Help
1.1. Additional Documentation Available
The following guides are available:
• Installation Guide — Covers initial installation of CloudPlatform. It aims to cover in full detail all the
steps and requirements to obtain a functioning cloud deployment.
At times, this guide mentions additional topics in the context of installation tasks, but does not
give full details on every topic. Additional details on many of these topics can be found in the
CloudPlatform Administration Guide. For example, security groups, firewall and load balancing
rules, IP address allocation, and virtual routers are covered in more detail in the Administration
Guide.
• Administration Guide — Discusses how to set up services for the end users of your cloud. Also
covers ongoing runtime management and maintenance. This guide discusses topics like domains,
accounts, service offerings, projects, guest networks, administrator alerts, virtual machines, storage,
and measuring resource usage.
• Developer's Guide — How to use the API to interact with CloudPlatform programmatically.
1.2. Citrix Knowledge Center
Troubleshooting articles by the Citrix support team are available in the Citrix Knowledge Center, at
support.citrix.com/product/cs/1.
1.3. Contacting Support
The support team is available to help customers plan and execute their installations. To contact the
support team, log in to the support portal at support.citrix.com/cloudsupport2 by using the account
credentials you received when you purchased your support contract.
1
http://support.citrix.com/product/cs/
2
http://support.citrix.com/cloudsupport
1
2
Chapter 2.
Concepts
2.1. What Is CloudPlatform?
CloudPlatform is a software platform that pools computing resources to build public, private, and
hybrid Infrastructure as a Service (IaaS) clouds. CloudPlatform manages the network, storage, and
compute nodes that make up a cloud infrastructure. Use CloudPlatform to deploy, manage, and
configure cloud computing environments.
Typical users are service providers and enterprises. With CloudPlatform, you can:
• Set up an on-demand, elastic cloud computing service. Service providers can sell self service virtual
machine instances, storage volumes, and networking configurations over the Internet.
• Set up an on-premise private cloud for use by employees. Rather than managing virtual machines in
the same way as physical machines, with CloudPlatform an enterprise can offer self-service virtual
machines to users without involving IT departments.
2.2. What Can CloudPlatform Do?
Multiple Hypervisor Support
CloudPlatform works with a variety of hypervisors. A single cloud deployment can contain multiple
hypervisor implementations. You have the complete freedom to choose the right hypervisor for your
workload.
CloudPlatform is designed to work with open source Xen and KVM hypervisors as well as enterprisegrade hypervisors such as Citrix XenServer, VMware vSphere, and Oracle VM (OVM).
3
Chapter 2. Concepts
Massively Scalable Infrastructure Management
CloudPlatform can manage tens of thousands of servers installed in multiple geographically distributed
datacenters. The centralized management server scales linearly, eliminating the need for intermediate
cluster-level management servers. No single component failure can cause cloud-wide outage. Periodic
maintenance of the management server can be performed without affecting the functioning of virtual
machines running in the cloud.
Automatic Configuration Management
CloudPlatform automatically configures each guest virtual machine’s networking and storage settings.
CloudPlatform internally manages a pool of virtual appliances to support the cloud itself. These
appliances offer services such as firewalling, routing, DHCP, VPN access, console proxy, storage
access, and storage replication. The extensive use of virtual appliances simplifies the installation,
configuration, and ongoing management of a cloud deployment.
Graphical User Interface
CloudPlatform offers an administrator's Web interface, used for provisioning and managing the cloud,
as well as an end-user's Web interface, used for running VMs and managing VM templates. The UI
can be customized to reflect the desired service provider or enterprise look and feel.
API and Extensibility
CloudPlatform provides an API that gives programmatic access to all the management features
available in the UI. This API enables the creation of command line tools and new user interfaces to
suit particular needs.
The CloudPlatform pluggable allocation architecture allows the creation of new types of allocators for
the selection of storage and hosts.
High Availability
CloudPlatform has a number of features to increase the availability of the system. The Management
Server itself, which is the main controlling software at the heart of CloudPlatform, may be deployed
in a multi-node installation where the servers are load balanced. MySQL may be configured to use
replication to provide for a manual failover in the event of database loss. For the hosts, CloudPlatform
supports NIC bonding and the use of separate networks for storage as well as iSCSI Multipath.
2.3. Deployment Architecture Overview
A CloudPlatform installation consists of two parts: the Management Server and the cloud infrastructure
that it manages. When you set up and manage a CloudPlatform cloud, you provision resources such
as hosts, storage devices, and IP addresses into the Management Server, and the Management
Server manages those resources.
The minimum production installation consists of one machine running the CloudPlatform Management
Server and another machine to act as the cloud infrastructure (in this case, a very simple infrastructure
consisting of one host running hypervisor software). In a trial installation, a single machine can act as
both the Management Server and the hypervisor host (using the KVM hypervisor).
4
Management Server Overview
A more full-featured installation consists of a highly-available multi-node Management Server
installation and up to thousands of hosts using any of several advanced networking setups. For
information about deployment options, see Choosing a Deployment Architecture in the Installation
Guide.
2.3.1. Management Server Overview
The Management Server is the CloudPlatform software that manages cloud resources. By interacting
with the Management Server through its UI or API, you can configure and manage your cloud
infrastructure.
The Management Server runs on a dedicated server or VM. It controls allocation of virtual machines
to hosts and assigns storage and IP addresses to the virtual machine instances. The Management
Server runs in a Tomcat container and uses a MySQL database for persistence.
The machine where the Management Server runs must meet the system requirements described in
Minimum System Requirements in the Installation Guide.
The Management Server:
• Provides the web user interface for the administrator and a reference user interface for end users.
• Provides the APIs for CloudPlatform.
• Manages the assignment of guest VMs to particular hosts.
• Manages the assignment of public and private IP addresses to particular accounts.
• Manages the allocation of storage to guests as virtual disks.
• Manages snapshots, templates, and ISO images, possibly replicating them across data centers.
• Provides a single point of configuration for the cloud.
2.3.2. Cloud Infrastructure Overview
The Management Server manages one or more zones (typically, datacenters) containing host
computers where guest virtual machines will run. The cloud infrastructure is organized as follows:
• Region: To increase reliability of the cloud, you can optionally group resources into multiple
geographic regions. A region consists of one or more zones.
5
Chapter 2. Concepts
• Zone: Typically, a zone is equivalent to a single datacenter. A zone consists of one or more pods
and secondary storage.
• Pod: A pod is usually one rack of hardware that includes a layer-2 switch and one or more clusters.
• Cluster: A cluster consists of one or more hosts and primary storage.
• Host: A single compute node within a cluster. The hosts are where the actual cloud services run in
the form of guest virtual machines.
• Primary storage is associated with a cluster, and it can also be provisioned on a zone-wide basis. It
stores the disk volumes for all the VMs running on hosts in that cluster.
• Secondary storage is associated with a zone, and it can also be provisioned as object storage that
is available throughout the cloud. It stores templates, ISO images, and disk volume snapshots.
More Information
For more information, see Chapter 3, Cloud Infrastructure Concepts.
2.3.3. Networking Overview
CloudPlatform offers two types of networking scenario:
6
Networking Overview
• Basic. Provides a single network where guest isolation can be provided through layer-3 means such
as security groups (IP address source filtering).
• Advanced. For more sophisticated network topologies. This network model provides the most
flexibility in defining guest networks and providing guest isolation.
For more details, see Network Setup in the Installation Guide.
7
8
Chapter 3.
Cloud Infrastructure Concepts
3.1. About Regions
To increase reliability of the cloud, you can optionally group resources into multiple geographic
regions. A region is the largest available organizational unit within a CloudPlatform deployment. A
region is made up of several availability zones, where each zone is 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.
Regions are visible to the end user. When a user starts a guest VM on a particular CloudPlatform
Management Server, the user is implicitly selecting that region for their guest. Users might also be
required to copy their private templates to additional regions to enable creation of guest VMs using
their templates in those regions.
3.2. About Zones
A zone is the second largest organizational unit within a CloudPlatform deployment. A zone typically
corresponds to a single datacenter, although it is permissible to have multiple zones in a datacenter.
9
Chapter 3. Cloud Infrastructure Concepts
The benefit of organizing infrastructure into zones is to provide physical isolation and redundancy. For
example, each zone can have its own power supply and network uplink, and the zones can be widely
separated geographically (though this is not required).
A zone consists of:
• One or more pods. Each pod contains one or more clusters of hosts and one or more primary
storage servers.
• (Optional) If zone-wide primary storage is desired, a zone may contain one or more primary storage
servers, which are shared by all the pods in the zone. (Supported for KVM and VMware hosts)
• Secondary storage, which is shared by all the pods in the zone.
Zones are visible to the end user. When a user starts a guest VM, the user must select a zone for
their guest. Users might also be required to copy their private templates to additional zones to enable
creation of guest VMs using their templates in those zones.
Zones can be public or private. Public zones are visible to all users. This means that any user may
create a guest in that zone. Private zones are reserved for a specific domain. Only users in that
domain or its subdomains may create guests in that zone.
Hosts in the same zone are directly accessible to each other without having to go through a firewall.
Hosts in different zones can access each other through statically configured VPN tunnels.
10
About Pods
For each zone, the administrator must decide the following.
• How many pods to place in a zone.
• How many clusters to place in each pod.
• How many hosts to place in each cluster.
• (Optional) If zone-wide primary storage is being used, decide how many primary storage servers to
place in each zone and total capacity for these storage servers. (Supported for KVM and VMware
hosts)
• How many primary storage servers to place in each cluster and total capacity for these storage
servers.
• How much secondary storage to deploy in a zone.
When you add a new zone, you will be prompted to configure the zone’s physical network and add the
first pod, cluster, host, primary storage, and secondary storage.
(VMware) In order to support zone-wide functions for VMware, CloudPlatform is aware of VMware
Datacenters and can map each Datacenter to a CloudPlatform zone. To enable features like storage
live migration and zone-wide primary storage 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 can 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 introduced in CloudPlatform 4.2, such as zone-wide primary storage and live storage
migration, will not be available in that zone.
3.3. About Pods
A pod often represents a single rack. Hosts in the same pod are in the same subnet. A pod is the
third-largest organizational unit within a CloudPlatform deployment. Pods are contained within zones,
and zones can be contained within regions. Each zone can contain one or more pods. A pod consists
of one or more clusters of hosts and one or more primary storage servers. Pods are not visible to the
end user.
11
Chapter 3. Cloud Infrastructure Concepts
3.4. About Clusters
A cluster provides a way to group hosts. To be precise, a cluster is a XenServer server pool, a set
of KVM servers, a set of OVM hosts, or a VMware cluster preconfigured in vCenter. The hosts in a
cluster all have identical hardware, run the same hypervisor, are on the same subnet, and access the
same shared primary storage. Virtual machine instances (VMs) can be live-migrated from one host to
another within the same cluster without interrupting service to the user.
A cluster is the fourth-largest organizational unit within a CloudPlatform deployment. Clusters
are contained within pods, pods are contained within zones, and zones can be contained within
regions. Size of the cluster is only limited by the underlying hypervisor, although the CloudPlatform
recommends you stay below the theoretically allowed maximum cluster size in most cases.
A cluster consists of one or more hosts and one or more primary storage servers.
Even when local storage is used, clusters are still required. In this case, there is just one host per
cluster.
(VMware) If you use VMware hypervisor hosts in your CloudPlatform deployment, each VMware
cluster is managed by a vCenter server. The CloudPlatform administrator must register the vCenter
12
About Hosts
server with CloudPlatform. There may be multiple vCenter servers per zone. Each vCenter server may
manage multiple VMware clusters.
3.5. About Hosts
A host is a single computer. Hosts provide the computing resources that run guest virtual machines.
Each host has hypervisor software installed on it to manage the guest VMs. For example, a host can
be a Citrix XenServer server, a Linux KVM-enabled server, or an ESXi server.
The host is the smallest organizational unit within a CloudPlatform deployment. Hosts are contained
within clusters, clusters are contained within pods, pods are contained within zones, and zones can be
contained within regions.
Hosts in a CloudPlatform deployment:
• Provide the CPU, memory, storage, and networking resources needed to host the virtual machines
• Interconnect using a high bandwidth TCP/IP network and connect to the Internet
• May reside in multiple data centers across different geographic locations
• May have different capacities (different CPU speeds, different amounts of RAM, etc.), although the
hosts within a cluster must all be homogeneous
Additional hosts can be added at any time to provide more capacity for guest VMs.
CloudPlatform automatically detects the amount of CPU and memory resources provided by the hosts.
Hosts are not visible to the end user. An end user cannot determine which host their guest has been
assigned to.
For a host to function in CloudPlatform, you must do the following:
• Install hypervisor software on the host
• Assign an IP address to the host
• Ensure the host is connected to the CloudPlatform Management Server.
3.6. About Primary Storage
Primary storage is associated with a cluster or (in KVM and VMware) a zone, and it stores the disk
volumes for all the VMs running on hosts.
You can add multiple primary storage servers to a cluster or zone. At least one is required. It is
typically located close to the hosts for increased performance. CloudPlatform manages the allocation
of guest virtual disks to particular primary storage devices.
It is useful to set up zone-wide primary storage when you want to avoid extra data copy operations.
With cluster-based primary storage, data in the primary storage is directly available only to VMs
within that cluster. If a VM in a different cluster needs 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 can be
unnecessarily time-consuming.
CloudPlatform is designed to work with all standards-compliant iSCSI and NFS servers that are
supported by the underlying hypervisor, including, for example:
13
Chapter 3. Cloud Infrastructure Concepts
• Dell EqualLogic™ for iSCSI
• Network Appliances filers for NFS and iSCSI
• Scale Computing for NFS
If you intend to use only local disk for your installation, you can skip adding separate primary storage.
3.7. About Secondary Storage
Secondary storage stores the following:
• Templates — OS images that can be used to boot VMs and can include additional configuration
information, such as installed applications
• ISO images — disc images containing data or bootable media for operating systems
• Disk volume snapshots — saved copies of VM data which can be used for data recovery or to
create new templates
The items in secondary storage are available to all hosts in the scope of the secondary storage, which
may be defined as per zone or per region.
CloudPlatform manages the allocation of guest virtual disks to particular primary storage devices.
To make items in secondary storage available to all hosts throughout the cloud, you can add object
storage in addition to the zone-based NFS Secondary Staging Store. It is not necessary to copy
templates and snapshots from one zone to another, as would be required when using zone NFS
alone. Everything is available everywhere.
Object storage is provided through third-party software such as Amazon Simple Storage Service (S3)
or any other object storage that supports the S3 interface. Additional third party object storages can be
integrated with CloudPlatform by writing plugin software that uses the object storage plugin capability.
CloudPlatform provides some plugins which we have already written for you using this storage plugin
capability. The provided plugins are for OpenStack Object Storage (Swift, swift.openstack.org1)
and Amazon Simple Storage Service (S3) object storage. The S3 plugin can be used for any object
storage that supports the Amazon S3 interface. When using one of these storage plugins, you
configure Swift or S3 storage for the entire CloudPlatform, then set up the NFS Secondary Staging
Store for each zone. The NFS storage in each zone acts as a staging area through which all templates
and other secondary storage data pass before being forwarded to Swift or S3. The backing object
storage acts as a cloud-wide resource, making templates and other data available to any zone in the
cloud.
There is no hierarchy in the Swift storage, just one Swift container per storage object. Any secondary
storage in the whole cloud can pull a container from Swift at need.
3.8. About Physical Networks
Part of adding a zone is setting up the physical network. One or (in an advanced zone) more physical
networks can be associated with each zone. The network corresponds to a NIC on the hypervisor
host. Each physical network can carry one or more types of network traffic. The choices of traffic
1
http://swift.openstack.org
14
Basic Zone Network Traffic Types
type for each network vary depending on whether you are creating a zone with basic networking or
advanced networking.
A physical network is the actual network hardware and wiring in a zone. A zone can have multiple
physical networks. An administrator can:
• Add/Remove/Update physical networks in a zone
• Configure VLANs on the physical network
• Configure a name so the network can be recognized by hypervisors
• Configure the service providers (firewalls, load balancers, etc.) available on a physical network
• Configure the IP addresses trunked to a physical network
• Specify what type of traffic is carried on the physical network, as well as other properties like
network speed
3.8.1. Basic Zone Network Traffic Types
When basic networking is used, there can be only one physical network in the zone. That physical
network carries the following traffic types:
• Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with
each other over a network that can be referred to as the guest network. Each pod in a basic zone
is a broadcast domain, and therefore each pod has a different IP range for the guest network. The
administrator must configure the IP range for each pod.
• Management. When CloudPlatform’s internal resources communicate with each other, they
generate management traffic. This includes communication between hosts, system VMs (VMs
used by CloudPlatform to perform various tasks in the cloud), and any other component that
communicates directly with the CloudPlatform Management Server. You must configure the IP
range for the system VMs to use.
Note
We strongly recommend the use of separate NICs for management traffic and guest traffic.
• Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs
must be allocated for this purpose. End users can use the CloudPlatform UI to acquire these IPs
to implement NAT between their guest network and the public network, as described in Acquiring
a New IP Address. Public traffic is generated only in EIP-enabled basic zones. For information on
Elastic IP, see Section 16.18, “About Elastic IP”.
• Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage
VM and secondary storage servers. CloudPlatform uses a separate Network Interface Controller
(NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on
a high bandwidth network allows fast template and snapshot copying. You must configure the IP
range to use for the storage network.
In a basic network, configuring the physical network is fairly straightforward. In most cases, you only
need to configure one guest network to carry traffic that is generated by guest VMs. If you use a
NetScaler load balancer and enable its elastic IP and elastic load balancing (EIP and ELB) features,
15
Chapter 3. Cloud Infrastructure Concepts
you must also configure a network to carry public traffic. CloudPlatform takes care of presenting the
necessary network configuration steps to you in the UI when you add a new zone.
3.8.2. Basic Zone Guest IP Addresses
When basic networking is used, CloudPlatform will assign IP addresses in the CIDR of the pod to the
guests in that pod. The administrator must add a direct IP range on the pod for this purpose. These
IPs are in the same VLAN as the hosts.
3.8.3. Advanced Zone Network Traffic Types
When advanced networking is used, there can be multiple physical networks in the zone. Each
physical network can carry one or more traffic types, and you need to let CloudPlatform know which
type of network traffic you want each network to carry. The traffic types in an advanced zone are:
• Guest. When end users run VMs, they generate guest traffic. The guest VMs communicate with
each other over a network that can be referred to as the guest network. This network can be
isolated or shared. In an isolated guest network, the administrator needs to reserve VLAN ranges to
provide isolation for each CloudPlatform account’s network (potentially a large number of VLANs). In
a shared guest network, all guest VMs share a single network.
• Management. When CloudPlatform’s internal resources communicate with each other, they
generate management traffic. This includes communication between hosts, system VMs (VMs
used by CloudPlatform to perform various tasks in the cloud), and any other component that
communicates directly with the CloudPlatform Management Server. You must configure the IP
range for the system VMs to use.
• Public. Public traffic is generated when VMs in the cloud access the Internet. Publicly accessible IPs
must be allocated for this purpose. End users can use the CloudPlatform UI to acquire these IPs to
implement NAT between their guest network and the public network, as described in “Acquiring a
New IP Address” in the Administration Guide.
• Storage. Traffic such as VM templates and snapshots, which is sent between the secondary storage
VM and secondary storage servers. CloudPlatform uses a separate Network Interface Controller
(NIC) named storage NIC for storage network traffic. Use of a storage NIC that always operates on
a high bandwidth network allows fast template and snapshot copying. You must configure the IP
range to use for the storage network.
These traffic types can each be on a separate physical network, or they can be combined with certain
restrictions. When you use the Add Zone wizard in the UI to create a new zone, you are guided into
making only valid choices.
3.8.4. Advanced Zone Guest IP Addresses
When advanced networking is used, the administrator can create additional networks for use by the
guests. These networks can span the zone and be available to all accounts, or they can be scoped
to a single account, in which case only the named account may create guests that attach to these
networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may
provision thousands of these networks if desired. Additionally, the administrator can reserve a part of
the IP address space for non-CloudPlatform VMs and servers (see Section 16.15, “IP Reservation in
Isolated Guest Networks”).
16
Advanced Zone Public IP Addresses
3.8.5. Advanced Zone Public IP Addresses
When advanced networking is used, the administrator can create additional networks for use by the
guests. These networks can span the zone and be available to all accounts, or they can be scoped
to a single account, in which case only the named account may create guests that attach to these
networks. The networks are defined by a VLAN ID, IP range, and gateway. The administrator may
provision thousands of these networks if desired.
3.8.6. System Reserved IP Addresses
In each zone, you need to configure a range of reserved IP addresses for the management network.
This network carries communication between the CloudPlatform Management Server and various
system VMs, such as Secondary Storage VMs, Console Proxy VMs, and DHCP.
The reserved IP addresses must be unique across the cloud. You cannot, for example, have a host in
one zone which has the same private IP address as a host in another zone.
The hosts in a pod are assigned private IP addresses. These are typically RFC1918 addresses. The
Console Proxy and Secondary Storage system VMs are also allocated private IP addresses in the
CIDR of the pod that they are created in.
Make sure computing servers and Management Servers use IP addresses outside of the System
Reserved IP range. For example, suppose the System Reserved IP range starts at 192.168.154.2 and
ends at 192.168.154.7. CloudPlatform can use .2 to .7 for System VMs. This leaves the rest of the pod
CIDR, from .8 to .254, for the Management Server and hypervisor hosts.
In all zones:
Provide private IPs for the system in each pod and provision them in CloudPlatform.
For KVM and XenServer, the recommended number of private IPs per pod is one per host. If you
expect a pod to grow, add enough private IPs now to accommodate the growth.
In a zone that uses advanced networking:
When advanced networking is being used, the number of private IP addresses available in each pod
varies depending on which hypervisor is running on the nodes in that pod. Citrix XenServer and KVM
use link-local addresses, which in theory provide more than 65,000 private IP addresses within the
address block. As the pod grows over time, this should be more than enough for any reasonable
number of hosts as well as IP addresses for guest virtual routers. VMWare ESXi, by contrast uses
any administrator-specified subnetting scheme, and the typical administrator provides only 255 IPs
per pod. Since these are shared by physical machines, the guest virtual router, and other entities, it is
possible to run out of private IPs when scaling up a pod whose nodes are running ESXi.
To ensure adequate headroom to scale private IP space in an ESXi pod that uses advanced
networking, use one or more of the following techniques:
• Specify a larger CIDR block for the subnet. A subnet mask with a /20 suffix will provide more than
4,000 IP addresses.
• Create multiple pods, each with its own subnet. For example, if you create 10 pods and each pod
has 255 IPs, this will provide 2,550 IP addresses.
For vSphere with advanced networking, we recommend provisioning enough private IPs for your total
number of customers, plus enough for the required CloudPlatform System VMs. Typically, about 10
additional IPs are required for the System VMs. For more information about System VMs, see Working
with System Virtual Machines in the Administrator's Guide.
17
18
Chapter 4.
Accounts
4.1. Accounts, Users, and Domains
Accounts
An account typically represents a customer of the service provider or a department in a large
organization. Multiple users can exist in an account.
Domains
Accounts are grouped by domains. Domains usually contain multiple accounts that have some logical
relationship to each other and a set of delegated administrators with some authority over the domain
and its subdomains. For example, a service provider with several resellers could create a domain for
each reseller.
For each account created, the Cloud installation creates three different types of user accounts: root
administrator, domain administrator, and user.
Users
Users are like aliases in the account. Users in the same account are not isolated from each other, but
they are isolated from users in other accounts. Most installations need not surface the notion of users;
they just have one user per account. The same user cannot belong to multiple accounts.
Username is unique in a domain across accounts in that domain. The same username can exist in
other domains, including sub-domains. Domain name can repeat only if the full pathname from root is
unique. For example, you can create root/d1, as well as root/foo/d1, and root/sales/d1.
Administrators are accounts with special privileges in the system. There may be multiple
administrators in the system. Administrators can create or delete other administrators, and change the
password for any user in the system.
Domain Administrators
Domain administrators can perform administrative operations for users who belong to that domain.
Domain administrators do not have visibility into physical servers or other domains.
Root Administrator
Root administrators have complete access to the system, including managing templates, service
offerings, customer care administrators, and domains
Resource Ownership
Resources belong to the account, not individual users in that account. For example, billing, resource
limits, and so on are maintained by the account, not the users. A user can operate on any resource in
the account provided the user has privileges for that operation. The privileges are determined by the
role. A root administrator can change the ownership of any virtual machine from one account to any
other account by using the assignVirtualMachine API. A domain or sub-domain administrator can do
the same for VMs within the domain from one account to any other account in the domain or any of its
sub-domains.
19
Chapter 4. Accounts
4.1.1. Dedicating Resources to Accounts and Domains
The root administrator can dedicate resources to a specific domain or account that needs private
infrastructure for additional security or performance guarantees. A zone, pod, cluster, or host can be
reserved by the root administrator for a specific domain or account. Only users in that domain or its
subdomain may use the infrastructure. For example, only users in a given domain can create guests in
a zone dedicated to that domain.
There are several types of dedication available:
• Explicit dedication. A zone, pod, cluster, or host is dedicated to an account or domain by the root
administrator during initial deployment and configuration.
• Strict implicit dedication. A host will not be shared across multiple accounts. For example, strict
implicit dedication is useful for deployment of certain types of applications, such as desktops, where
no host can be shared between different accounts without violating the desktop software's terms of
license.
• Preferred implicit dedication. The VM will be deployed in dedicated infrastructure if possible.
Otherwise, the VM can be deployed in shared infrastructure.
4.1.1.1. How to Dedicate a Zone, Cluster, Pod, or Host to an Account or
Domain
For explicit dedication: When deploying a new zone, pod, cluster, or host, the root administrator can
click the Dedicated checkbox, then choose a domain or account to own the resource.
To explicitly dedicate an existing zone, pod, cluster, or host: log in as the root admin, find the resource
in the UI, and click the Dedicate button.
For implicit dedication: The administrator creates a compute service offering and in the Deployment
Planner field, chooses ImplicitDedicationPlanner. Then in Planner Mode, the administrator specifies
either Strict or Preferred, depending on whether it is permissible to allow some use of shared
resources when dedicated resources are not available. Whenever a user creates a VM based on this
service offering, it is allocated on one of the dedicated hosts.
4.1.1.2. How to Use Dedicated Hosts
To use an explicitly dedicated host, use the explicit-dedicated type of affinity group (see
Section 11.8.1, “Affinity Groups”). For example, when creating a new VM, an end user can choose to
place it on dedicated infrastructure. This operation will succeed only if some infrastructure has already
been assigned as dedicated to the user's account or domain.
4.1.1.3. Behavior of Dedicated Hosts, Clusters, Pods, and Zones
The administrator can live migrate VMs away from dedicated hosts if desired, whether the destination
is a host reserved for a different account/domain or a host that is shared (not dedicated to any
particular account or domain). CloudPlatform will generate an alert, but the operation is allowed.
Dedicated hosts can be used in conjunction with host tags. If both a host tag and dedication are
requested, the VM will be placed only on a host that meets both requirements. If there is no dedicated
resource available to that user that also has the host tag requested by the user, then the VM will not
deploy.
20
Using an LDAP Server for User Authentication
If you delete an account or domain, any hosts, clusters, pods, and zones that were dedicated to it are
freed up. They will now be available to be shared by any account or domain, or the administrator may
choose to re-dedicate them to a different account or domain.
System VMs and virtual routers affect the behavior of host dedication. System VMs and virtual routers
are owned by the CloudPlatform system account, and they can be deployed on any host. They do
not adhere to explicit dedication. The presence of system vms and virtual routers on a host makes it
unsuitable for strict implicit dedication. The host can not be used for strict implicit dedication, because
the host already has VMs of a specific account (the default system account). However, a host with
system VMs or virtual routers can be used for preferred implicit dedication.
4.2. Using an LDAP Server for User Authentication
You can use an external LDAP server, such as Microsoft Active Directory or ApacheDS, to
authenticate CloudPlatform end-users. Just map CloudPlatform accounts to the corresponding LDAP
accounts using a query filter. The query filter is written using the query syntax of the particular LDAP
server, and can include special wildcard characters provided by CloudPlatform for matching common
values such as the user’s email address and name. CloudPlatform will search the external LDAP
directory tree starting at a specified base directory and return the distinguished name (DN) and
password of the matching user. This information along with the given password is used to authenticate
the user.
4.2.1. Configuring an LDAP Server
You can add or remove an LDAP server to CloudPlatform for user authentication. To set up LDAP
authentication, you provide the following:
• Hostname or IP address and listening port of the LDAP server
• Base directory and query filter
• Search user DN credentials, which give CloudPlatform permission to search on the LDAP server
• SSL keystore and password, if SSL is used
4.2.1.1. Adding an LDAP Server
1. Log in to the CloudPlatform.
2. From the left navigational bar, click Global Settings.
3. From the Select view drop down, select LDAP Configuration.
4. Click Configure LDAP.
The Configure LDAP dialog is displayed.
21
Chapter 4. Accounts
5. Specify the following:
• Bind DN: The full distinguished name (DN), including common name (CN), of an LDAP user
account that has the necessary privileges to search users.
For example:
cn=admin,cn=users,dc=mycom,dc=com
This user account must have at least domain user privileges.
• Bind Password: The password used in association with the Bind DN user account.
• Hostname: Hostname or IP address.
• Query Filter: Searches external LDAP directory tree for corresponding CloudPlatform accounts.
The query filter is written by using the query syntax of the particular LDAP server, and can
include special wild card characters provided by CloudPlatform for matching common values,
such as the user’s email address and name.
• Port: The Listening port of the LDAP server. The default is 389.
• SSL: Specify SSL Trust Store and password, if SSL is used.
• Trust Store:
• Trust Store Password:
22
Example LDAP Configuration Commands
6. Click OK.
4.2.1.2. Removing an LDAP Configuration
1. Log in to the CloudPlatform.
2. From the left navigational bar, click Global Settings.
3. From the Select view drop down, select LDAP Configuration.
4. In the Quick View, click Remove LDAP.
Alternatively, you can click Remove LDAP in the LDAP Configuration Details page.
4.2.2. Example LDAP Configuration Commands
To understand the examples in this section, you need to know the basic concepts behind calling the
CloudPlatform API, which are explained in the Developer’s Guide.
The following shows an example invocation of ldapConfig with an ApacheDS LDAP server
http://127.0.0.1:8080/client/api?command=ldapConfig&hostname=127.0.0.1&searchbase=ou
%3Dtesting%2Co%3Dproject&queryfilter=%28%26%28uid%3D%25u%29%29&binddn=cn%3DJohn+Singh%2Cou
%3Dtesting%2Co%project&bindpass=secret&port=10389&ssl=true&truststore=C%3A%2Fcompany%2Finfo
%2Ftrusted.ks&truststorepass=secret&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
The command must be URL-encoded. Here is the same example without the URL encoding:
http://127.0.0.1:8080/client/api?command=ldapConfig
&hostname=127.0.0.1
&searchbase=ou=testing,o=project
&queryfilter=(&(%uid=%u))
&binddn=cn=John+Singh,ou=testing,o=project
&bindpass=secret
&port=10389
&ssl=true
&truststore=C:/company/info/trusted.ks
&truststorepass=secret
&response=json
&apiKey=YourAPIKey&signature=YourSignatureHash
The following shows a similar command for Active Directory. Here, the search base is the testing
group within a company, and the users are matched up based on email address.
http://127.127.0.0:8080/client/api?command=ldapConfig&hostname=127.147.28.250&searchbase=OU
%3Dtesting%2CDC%3Dcompany&queryfilter=%28%26%28mail%3D
%25e%29%29 &binddn=CN%3DAdministrator%2COU%3Dtesting%2CDC
%3Dcompany&bindpass=1111_aaaa&port=389&response=json&apiKey=YourAPIKey&signature=YourSignatureHash
The next few sections explain some of the concepts you will need to know when filling out the
ldapConfig parameters.
4.2.3. Search Base
An LDAP query is relative to a given node of the LDAP directory tree, called the search base. The
search base is the distinguished name (DN) of a level of the directory tree below which all users can
be found. The users can be in the immediate base directory or in some subdirectory. The search base
may be equivalent to the organization, group, or domain name. The syntax for writing a DN varies
23
Chapter 4. Accounts
depending on which LDAP server you are using. A full discussion of distinguished names is outside
the scope of our documentation. The following table shows some examples of search bases to find
users in the testing department..
LDAP Server Example Search Base DN
ApacheDS ou=testing,o=project
Active Directory OU=testing, DC=company
4.2.4. Query Filter
The query filter is used to find a mapped user in the external LDAP server. The query filter should
uniquely map the CloudPlatform user to LDAP user for a meaningful authentication. For more
information about query filter syntax, consult the documentation for your LDAP server.
The CloudPlatform query filter wild cards are:
Query Filter Wildcard Description
%u User name
%e Email address
%n First and last name
4.2.4.1. Active Directory
The following examples assume that you are using Active Directory. Refer to user attributes from the
Active Directory schema.
If the CloudPlatform user name is the same as the LDAP user ID:
(sAMAccountName=%u)
If the CloudPlatform user name is the LDAP display name:
(displayName=%u)
To find a user by email address:
(mail=%e)
4.2.4.2. ApacheDS
If your LDAP server is ApacheDS, consider the following examples:
If the CloudPlatform user name is the same as the LDAP user ID:
(uid=%u)
To find a user by email address:
(mail=%e)
Enter the query filers in CloudPlatform in the following format:
24
Search User Bind DN
(&(sAMAccountName=%u) or (&(mail=%e))
4.2.5. Search User Bind DN
The bind DN is the user on the external LDAP server permitted to search the LDAP directory within the
defined search base. When the DN is returned, the DN and passed password are used to authenticate
the CloudPlatform user with an LDAP bind. A full discussion of bind DNs is outside the scope of our
documentation. The following table shows some examples of bind DNs.
LDAP Server Example Bind DN
ApacheDS cn=Administrator,dc=testing,ou=project,ou=org
Active Directory CN=Administrator, OU=testing, DC=company,
DC=com
4.2.6. SSL Keystore Path and Password
If the LDAP server requires SSL, you need to enable it in the ldapConfig command by setting the
parameters ssl, truststore, and truststorepass. Before enabling SSL for ldapConfig, you need to get
the certificate which the LDAP server is using and add it to a trusted keystore. You will need to know
the path to the keystore and the password.
25
26
Chapter 5.
User Services Overview
In addition to the physical and logical infrastructure of your cloud, and the CloudPlatform software and
servers, you also need a layer of user services so that people can actually make use of the cloud.
This means not just a user UI, but a set of options and resources that users can choose from, such
as templates for creating virtual machines, disk storage, and more. If you are running a commercial
service, you will be keeping track of what services and resources users are consuming and charging
them for that usage. Even if you do not charge anything for people to use your cloud – say, if the users
are strictly internal to your organization, or just friends who are sharing your cloud – you can still keep
track of what services they use and how much of them.
5.1. Service Offerings, Disk Offerings, Network Offerings,
and Templates
A user creating a new instance can make a variety of choices about its characteristics and capabilities.
CloudPlatform provides several ways to present users with choices when creating a new instance:
• Service Offerings, defined by the CloudPlatform administrator, provide a choice of CPU speed,
number of CPUs, RAM size, tags on the root disk, and other choices. See Creating a New Compute
Offering.
• Disk Offerings, defined by the CloudPlatform administrator, provide a choice of disk size for primary
data storage. See Creating a New Disk Offering.
• Network Offerings, defined by the CloudPlatform administrator, describe the feature set that is
available to end users from the virtual router or external networking devices on a given guest
network. See Network Offerings.
• Templates, defined by the CloudPlatform administrator or by any CloudPlatform user, are the
base OS images that the user can choose from when creating a new instance. For example,
CloudPlatform includes CentOS as a template. See Working with Templates.
In addition to these choices that are provided for users, there is another type of service offering
which is available only to the CloudPlatform root administrator, and is used for configuring virtual
infrastructure resources. For more information, see Upgrading a Virtual Router with System Service
Offerings.
27
28
Chapter 6.
User Interface
6.1. Supported Browsers
The CloudPlatform web-based UI is available in the following popular browsers:
• Mozilla Firefox 22 or greater
• Apple Safari, all versions packaged with Mac OS X 10.5 (Leopard) or greater
• Google Chrome, all versions starting from the year 2012
• Microsoft Internet Explorer 9 or greater
6.2. Log In to the UI
CloudPlatform provides a web-based UI that can be used by both administrators and end users. The
appropriate version of the UI is displayed depending on the credentials used to log in.
The URL to log in to CloudPlatform is: (substitute your own management server IP address)
http://<management-server-ip-address>:8080/client
On a fresh Management Server installation, a guided tour splash screen appears. On later visits, you’ll
see a login screen where you specify the following to proceed to your Dashboard:
Username
The user ID of your account. The default username is admin.
Password
The password associated with the user ID. The password for the default username is password.
Domain
If you are a root user, leave this field blank.
If you are a user in the sub-domains, enter the full path to the domain, excluding the root domain.
For example, suppose multiple levels are created under the root domain, such as Comp1/hr. The
users in the Comp1 domain should enter Comp1 in the Domain field, whereas the users in the Comp1/
sales domain should enter Comp1/sales.
For more guidance about the choices that appear when you log in to this UI, see Logging In as the
Root Administrator.
6.2.1. End User's UI Overview
The CloudPlatform UI helps users of cloud infrastructure to view and use their cloud resources,
including virtual machines, templates and ISOs, data volumes and snapshots, guest networks, and IP
addresses. If the user is a member or administrator of one or more CloudPlatform projects, the UI can
provide a project-oriented view.
29
Chapter 6. User Interface
6.2.2. Root Administrator's UI Overview
The CloudPlatform UI helps the CloudPlatform administrator provision, view, and manage the cloud
infrastructure, domains, user accounts, projects, and configuration settings. The first time you start the
UI after a fresh Management Server installation, you can choose to follow a guided tour to provision
your cloud infrastructure. On subsequent logins, the dashboard of the logged-in user appears.
The various links in this screen and the navigation bar on the left provide access to a variety of
administrative functions. The root administrator can also use the UI to perform all the same tasks that
are present in the end-user’s UI.
6.2.3. Logging In as the Root Administrator
After the Management Server software is installed and running, you can run the CloudPlatform user
interface. This UI is there to help you provision, view, and manage your cloud infrastructure.
1. Open your favorite Web browser and go to this URL. Substitute the IP address of your own
Management Server:
http://<management-server-ip-address>:8080/client
On a fresh Management Server installation, a guided tour splash screen appears. On later visits,
you’ll see a login screen where you can enter a user ID and password and proceed to your
Dashboard.
2. If you see the first-time splash screen, choose one of the following.
• Continue with basic setup. Choose this if you're just trying CloudPlatform, and you want
a guided walkthrough of the simplest possible configuration so that you can get started right
away. We'll help you set up a cloud with the following features: a single machine that runs
CloudPlatform software and uses NFS to provide storage; a single machine running VMs under
the XenServer or KVM hypervisor; and a shared public network.
The prompts in this guided tour should give you all the information you need, but if you want just
a bit more detail, you can follow along in the Trial Installation Guide.
• I have used CloudPlatform before. Choose this if you have already gone through a design
phase and planned a more sophisticated deployment, or you are ready to start scaling up a trial
cloud that you set up earlier with the basic setup screens. In the Administrator UI, you can start
using the more powerful features of CloudPlatform, such as advanced VLAN networking, high
availability, additional network elements such as load balancers and firewalls, and support for
multiple hypervisors including Citrix XenServer, KVM, and VMware vSphere.
The root administrator Dashboard appears.
3. You should set a new root administrator password. If you chose basic setup, you’ll be prompted to
create a new password right away. If you chose experienced user, use the steps in Section 6.2.4,
“Changing the Root Password”.
30
Changing the Root Password
Warning
You are logging in as the root administrator. This account manages the CloudPlatform
deployment, including physical infrastructure. The root administrator can modify configuration
settings to change basic functionality, create or delete user accounts, and take many actions that
should be performed only by an authorized person. Please change the default password to a
new, unique password.
6.2.4. Changing the Root Password
During installation and ongoing cloud administration, you will need to log in to the UI as the root
administrator. The root administrator account manages the CloudPlatform deployment, including
physical infrastructure. The root administrator can modify configuration settings to change basic
functionality, create or delete user accounts, and take many actions that should be performed only by
an authorized person. When first installing CloudPlatform, be sure to change the default password to a
new, unique value.
1. Open your favorite Web browser and go to this URL. Substitute the IP address of your own
Management Server:
http://<management-server-ip-address>:8080/client
2. Log in to the UI using the current root user ID and password. The default is admin, password.
3. Click Accounts.
4. Click the admin account name.
5. Click View Users.
6. Click the admin user name.
7.
Click the Change Password button.
8. Type the new password, and click OK.
6.3. Using SSH Keys for Authentication
In addition to the username and password authentication, CloudPlatform supports using SSH keys to
log in to the cloud infrastructure for additional security for your cloud infrastructure. You can use the
createSSHKeyPair API to generate the SSH keys.
Because each cloud user has their own ssh key, one cloud user cannot log in to another cloud user's
instances unless they share their ssh key files. Using a single SSH key pair, you can manage multiple
instances.
6.3.1. Creating an Instance from a Template that Supports SSH
Keys
Perform the following:
1. Create a new instance by using the template provided by CloudPlatform.
31
Chapter 6. User Interface
For more information on creating a new instance, see Section 11.4, “Creating VMs”.
2. Download the script file cloud-set-guest-sshkey from the following link:
http://download.cloud.com/templates/4.2/bindir/cloud-set-guest-sshkey.in
3. Copy the file to /etc/init.d.
4. Give the necessary permissions on the script:
chmod +x /etc/init.d/cloud-set-guest-sshkey
5. Run the script while starting up the operating system:
chkconfig --add cloud-set-guest-sshkey
6. Stop the instance.
6.3.2. Creating the SSH Keypair
You must make a call to the createSSHKeyPair api method. You can either use the CloudPlatform
python api library or the curl commands to make the call to the CloudPlatform api.
For example, make a call from the CloudPlatform server to create a SSH keypair called "keypair-doc"
for the admin account in the root domain:
Note
Ensure that you adjust these values to meet your needs. If you are making the API call from a
different server, your URL or port number will be different, and you will need to use the API keys.
1. Run the following curl command:
curl --globoff "http://localhost:8080/?command=createSSHKeyPair&name=keypairdoc&account=admin&domainid=1"
The output is something similar to what is given below:
<?xml version="1.0" encoding="ISO-8859-1"?><createsshkeypairresponse
cloud-stack-version="3.0.0.20120228045507"><keypair><name>keypairdoc</name><fingerprint>f6:77:39:d5:5e:77:02:22:6a:d8:7f:ce:ab:cd:b3:56</
fingerprint><privatekey>-----BEGIN RSA PRIVATE KEY----MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY----</privatekey></keypair></createsshkeypairresponse>
32
2. Copy the key data into a file. The file looks like this:
-----BEGIN RSA PRIVATE KEY----MIICXQIBAAKBgQCSydmnQ67jP6lNoXdX3noZjQdrMAWNQZ7y5SrEu4wDxplvhYci
dXYBeZVwakDVsU2MLGl/K+wefwefwefwefwefJyKJaogMKn7BperPD6n1wIDAQAB
AoGAdXaJ7uyZKeRDoy6wA0UmF0kSPbMZCR+UTIHNkS/E0/4U+6lhMokmFSHtu
mfDZ1kGGDYhMsdytjDBztljawfawfeawefawfawfawQQDCjEsoRdgkduTy
QpbSGDIa11Jsc+XNDx2fgRinDsxXI/zJYXTKRhSl/LIPHBw/brW8vzxhOlSOrwm7
VvemkkgpAkEAwSeEw394LYZiEVv395ar9MLRVTVLwpo54jC4tsOxQCBlloocK
lYaocpk0yBqqOUSBawfIiDCuLXSdvBo1Xz5ICTM19vgvEp/+kMuECQBzm
nVo8b2Gvyagqt/KEQo8wzH2THghZ1qQ1QRhIeJG2aissEacF6bGB2oZ7Igim5L14
4KR7OeEToyCLC2k+02UCQQCrniSnWKtDVoVqeK/zbB32JhW3Wullv5p5zUEcd
KfEEuzcCUIxtJYTahJ1pvlFkQ8anpuxjSEDp8x/18bq3
-----END RSA PRIVATE KEY-----
3. Save the file.
6.3.3. Creating an Instance
Ensure that you use the same SSH key name that you created.
Note
Creating an Instance
You cannot create the instance by using the GUI at this time and associate the instance with the
newly created SSH keypair.
A sample curl command to create a new instance is:
curl --globoff http://localhost:<port number>/?
command=deployVirtualMachine&zoneId=1&serviceOfferingId=18727021-7556-4110-9322d625b52e0813&templateId=e899c18ace13-4bbf-98a9-625c5026e0b5&securitygroupids=ff03f02f-9e3b-48f8-834d-91b822da40c5&account=admin
\&domainid=1&keypair=keypair-doc
Substitute the template, service offering and security group IDs (if you are using the security group
feature) that are in your cloud environment.
6.3.4. Logging In Using the SSH Keypair
To test your SSH key generation is successful, check whether you can log in to the cloud setup.
For example, from a Linux OS, run:
ssh -i ~/.ssh/keypair-doc <ip address>
The -i parameter directs the ssh client to use a ssh key found at ~/.ssh/keypair-doc.
6.3.5. Resetting SSH Keys
With the API command resetSSHKeyForVirtualMachine, a user can set or reset the SSH keypair
assigned to a virtual machine. A lost or compromised SSH keypair can be changed, and the user
can access the VM by using the new keypair. Just create or register a new keypair, then call
resetSSHKeyForVirtualMachine.
33
34
Chapter 7.
Using Projects to Organize Users and
Resources
7.1. Overview of Projects
Projects are used to organize people and resources. CloudPlatform users within a single domain can
group themselves into project teams so they can collaborate and share virtual resources such as VMs,
snapshots, templates, data disks, and IP addresses. CloudPlatform tracks resource usage per project
as well as per user, so the usage can be billed to either a user account or a project. For example, a
private cloud within a software company might have all members of the QA department assigned to
one project, so the company can track the resources used in testing while the project members can
more easily isolate their efforts from other users of the same cloud
You can configure CloudPlatform to allow any user to create a new project, or you can restrict that
ability to just CloudPlatform administrators. Once you have created a project, you become that
project’s administrator, and you can add others within your domain to the project. CloudPlatform
can be set up either so that you can add people directly to a project, or so that you have to send an
invitation which the recipient must accept. Project members can view and manage all virtual resources
created by anyone in the project (for example, share VMs). A user can be a member of any number of
projects and can switch views in the CloudPlatform UI to show only project-related information, such
as project VMs, fellow project members, project-related alerts, and so on.
The project administrator can pass on the role to another project member. The project administrator
can also add more members, remove members from the project, set new resource limits (as long as
they are below the global defaults set by the CloudPlatform administrator), and delete the project.
When the administrator removes a member from the project, resources created by that user, such as
VM instances, remain with the project. This brings us to the subject of resource ownership and which
resources can be used by a project.
Resources created within a project are owned by the project, not by any particular CloudPlatform
account, and they can be used only within the project. A user who belongs to one or more projects
can still create resources outside of those projects, and those resources belong to the user’s account;
they will not be counted against the project’s usage or resource limits. You can create project-level
networks to isolate traffic within the project and provide network services such as port forwarding,
load balancing, VPN, and static NAT. A project can also make use of certain types of resources from
outside the project, if those resources are shared. For example, a shared network or public template is
available to any project in the domain. A project can get access to a private template if the template’s
owner will grant permission. A project can use any service offering or disk offering available in its
domain; however, you can not create private service and disk offerings at the project level..
7.2. Configuring Projects
Before CloudPlatform users start using projects, the CloudPlatform administrator must set up various
systems to support them, including membership invitations, limits on project resources, and controls
on who can create projects.
7.2.1. Setting Up Invitations
CloudPlatform can be set up either so that project administrators can add people directly to a project,
or so that it is necessary to send an invitation which the recipient must accept. The invitation can
be sent by email or through the user’s CloudPlatform account. If you want administrators to use
invitations to add members to projects, turn on and set up the invitations feature in CloudPlatform.
35
Chapter 7. Using Projects to Organize Users and Resources
1. Log in as administrator to the CloudPlatform UI.
2. In the left navigation, click Global Settings.
3.
In the search box, type project and click the search button.
4. In the search results, you can see a few other parameters you need to set to control how
invitations behave. The table below shows global configuration parameters related to project
invitations. Click the edit button to set each parameter.
Configuration Parameters Description
project.invite.required Set to true to turn on the invitations feature.
project.email.sender The email address to show in the From field of
invitation emails.
project.invite.timeout Amount of time to allow for a new member to
respond to the invitation.
project.smtp.host Name of the host that acts as an email server
to handle invitations.
project.smtp.password (Optional) Password required by
the SMTP server. You must also
set project.smtp.username and set
project.smtp.useAuth to true.
project.smtp.port SMTP server’s listening port.
project.smtp.useAuth Set to true if the SMTP server requires a
username and password.
project.smtp.username (Optional) User name required by the
SMTP server for authentication. You must
also set project.smtp.password and set
project.smtp.useAuth to true..
5. Restart the Management Server:
service cloud-management restart
7.2.2. Setting Resource Limits for Projects
The CloudPlatform administrator can set global default limits to control the amount of resources that
can be owned by each project in the cloud. This serves to prevent uncontrolled usage of resources
such as snapshots, IP addresses, and virtual machine instances. Domain administrators can override
these resource limits for individual projects with their domains, as long as the new limits are below the
global defaults set by the CloudPlatform root administrator. The root administrator can also set lower
resource limits for any project in the cloud
7.2.3. Setting Project Creator Permissions
You can configure CloudPlatform to allow any user to create a new project, or you can restrict that
ability to just CloudPlatform administrators.
1. Log in as administrator to the CloudPlatform UI.
2. In the left navigation, click Global Settings.
36
Creating a New Project
3. In the search box, type allow.user.create.projects.
4.
Click the edit button to set the parameter.
allow.user.create.projects Set to true to allow end users to create
projects. Set to false if you want only the
CloudPlatform root administrator and domain
administrators to create projects.
5. Restart the Management Server.
# service cloud-management restart
7.3. Creating a New Project
CloudPlatform administrators and domain administrators can create projects. If the global
configuration parameter allow.user.create.projects is set to true, end users can also create projects.
1. Log in as administrator to the CloudPlatform UI.
2. In the left navigation, click Projects.
3. In Select view, click Projects.
4. Click New Project.
5. Give the project a name and description for display to users, then click Create Project.
6. A screen appears where you can immediately add more members to the project. This is optional.
Click Next when you are ready to move on.
7. Click Save.
7.4. Adding Members to a Project
New members can be added to a project by the project’s administrator, the domain administrator of
the domain where the project resides or any parent domain, or the CloudPlatform root administrator.
There are two ways to add members in CloudPlatform, but only one way is enabled at a time:
• If invitations have been enabled, you can send invitations to new members.
• If invitations are not enabled, you can add members directly through the UI.
7.4.1. Sending Project Membership Invitations
Use these steps to add a new member to a project if the invitations feature is enabled in the cloud as
described in Section 7.2.1, “Setting Up Invitations”. If the invitations feature is not turned on, use the
procedure in Adding Project Members From the UI.
1. Log in to the CloudPlatform UI.
2. In the left navigation, click Projects.
3. In Select View, choose Projects.
4. Click the name of the project you want to work with.
37
Chapter 7. Using Projects to Organize Users and Resources
5. Click the Invitations tab.
6. In Add by, select one of the following:
a. Account – The invitation will appear in the user’s Invitations tab in the Project View. See Using
the Project View.
b. Email – The invitation will be sent to the user’s email address. Each emailed invitation
includes a unique code called a token which the recipient will provide back to CloudPlatform
when accepting the invitation. Email invitations will work only if the global parameters related
to the SMTP server have been set. See Section 7.2.1, “Setting Up Invitations”.
7. Type the user name or email address of the new member you want to add, and click Invite. Type
the CloudPlatform user name if you chose Account in the previous step. If you chose Email, type
the email address. You can invite only people who have an account in this cloud within the same
domain as the project. However, you can send the invitation to any email address.
8. To view and manage the invitations you have sent, return to this tab. When an invitation is
accepted, the new member will appear in the project’s Accounts tab.
7.4.2. Adding Project Members From the UI
The steps below tell how to add a new member to a project if the invitations feature is not enabled
in the cloud. If the invitations feature is enabled cloud,as described in Section 7.2.1, “Setting Up
Invitations”, use the procedure in Section 7.4.1, “Sending Project Membership Invitations”.
1. Log in to the CloudPlatform UI.
2. In the left navigation, click Projects.
3. In Select View, choose Projects.
4. Click the name of the project you want to work with.
5. Click the Accounts tab. The current members of the project are listed.
6. Type the account name of the new member you want to add, and click Add Account. You can add
only people who have an account in this cloud and within the same domain as the project.
7.5. Accepting a Membership Invitation
If you have received an invitation to join a CloudPlatform project, and you want to accept the invitation,
follow these steps:
1. Log in to the CloudPlatform UI.
2. In the left navigation, click Projects.
3. In Select View, choose Invitations.
4. If you see the invitation listed onscreen, click the Accept button.
Invitations listed on screen were sent to you using your CloudPlatform account name.
5. If you received an email invitation, click the Enter Token button, and provide the project ID and
unique ID code (token) from the email.
38
Suspending or Deleting a Project
7.6. Suspending or Deleting a Project
When a project is suspended, it retains the resources it owns, but they can no longer be used. No new
resources or members can be added to a suspended project.
When a project is deleted, its resources are destroyed, and member accounts are removed from the
project. The project’s status is shown as Disabled pending final deletion.
A project can be suspended or deleted by the project administrator, the domain administrator of the
domain the project belongs to or of its parent domain, or the CloudPlatform root administrator.
1. Log in to the CloudPlatform UI.
2. In the left navigation, click Projects.
3. In Select View, choose Projects.
4. Click the name of the project.
5. Click one of the buttons:
To delete, use
To suspend, use
7.7. Using the Project View
If you are a member of a project, you can use CloudPlatform’s project view to see project members,
resources consumed, and more. The project view shows only information related to one project. It is a
useful way to filter out other information so you can concentrate on a project status and resources.
1. Log in to the CloudPlatform UI.
2. Click Project View.
3. The project dashboard appears, showing the project’s VMs, volumes, users, events, network
settings, and more. From the dashboard, you can:
• Click the Accounts tab to view and manage project members. If you are the project
administrator, you can add new members, remove members, or change the role of a member
from user to admin. Only one member at a time can have the admin role, so if you set another
user’s role to admin, your role will change to regular user.
• (If invitations are enabled) Click the Invitations tab to view and manage invitations that have
been sent to new project members but not yet accepted. Pending invitations will remain in this
list until the new member accepts, the invitation timeout is reached, or you cancel the invitation.
39
40
Chapter 8.
Steps to Provisioning Your Cloud
Infrastructure
This section tells how to add regions, zones, pods, clusters, hosts, storage, and networks to your
cloud. If you are unfamiliar with these entities, please begin by looking through Chapter 3, Cloud
Infrastructure Concepts.
8.1. Overview of Provisioning Steps
After the Management Server is installed and running, you can add the compute resources for it to
manage. For an overview of how a CloudPlatform cloud infrastructure is organized, see Section 2.3.2,
“Cloud Infrastructure Overview”.
To provision the cloud infrastructure, or to scale it up at any time, follow these procedures:
1. Define regions (optional). See Section 8.2, “Adding Regions (optional)”.
2. Add a zone to the region. See Section 8.3, “Adding a Zone”.
3. Add more pods to the zone (optional). See Section 8.4, “Adding a Pod”.
4. Add more clusters to the pod (optional). See Section 8.5, “Adding a Cluster”.
5. Add more hosts to the cluster (optional). See Section 8.6, “Adding a Host”.
6. Add primary storage to the cluster. See Section 8.7, “Adding Primary Storage”.
7. Add secondary storage to the zone. See Section 8.8, “Adding Secondary Storage”.
8. Initialize and test the new cloud. See Section 8.9, “Initialize and Test”.
When you have finished these steps, you will have a deployment with the following basic structure:
41
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
8.2. Adding Regions (optional)
Grouping your cloud resources into geographic regions is an optional step when provisioning the
cloud. For an overview of regions, see Section 3.1, “About Regions”.
8.2.1. The First Region: The Default Region
If you do not take action to define regions, then all the zones in your cloud will be automatically
grouped into a single default region. This region is assigned the region ID of 1. You can change the
name or URL of the default region by displaying the region in the CloudPlatform UI and clicking the
Edit button.
8.2.2. Adding a Region
Use these steps to add a second region in addition to the default region.
1. Each region has its own CloudPlatform instance. Therefore, the first step of creating a new
region is to install the Management Server software, on one or more nodes, in the geographic
area where you want to set up the new region. Use the steps in the Installation guide. When
you come to the step where you set up the database, use the additional command-line flag -r
<region_id> to set a region ID for the new region. The default region is automatically assigned
a region ID of 1, so your first additional region might be region 2.
cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e
<encryption_type> -m <management_server_key> -k <database_key> -r <region_id>
2. By the end of the installation procedure, the Management Server should have been started. Be
sure that the Management Server installation was successful and complete.
42
Adding Third and Subsequent Regions
3. Now add the new region to region 1 in CloudPlatform.
a. Log in to CloudPlatform in the first region as root administrator (that is, log in to
<region.1.IP.address>:8080/client).
b. In the left navigation bar, click Regions.
c. Click Add Region. In the dialog, fill in the following fields:
• ID. A unique identifying number. Use the same number you set in the database during
Management Server installation in the new region; for example, 2.
• Name. Give the new region a descriptive name.
• Endpoint. The URL where you can log in to the Management Server in the new region. This
has the format <region.2.IP.address>:8080/client.
4. Now perform the same procedure in reverse. Log in to region 2, and add region 1.
5. Copy the account, user, and domain tables from the region 1 database to the region 2 database.
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.
a. First, run this command to copy the contents of the database:
# mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain
> region1.sql
b. Then run this command to put the data onto the region 2 database:
# mysql -u root -p<mysql_password> -h <region2_db_host> cloud < region1.sql
6. Remove project accounts. Run these commands on the region 2 database:
mysql> delete from account where type = 5;
7. Set the default zone as null:
mysql> update account set default_zone_id = null;
8. Restart the Management Servers in region 2.
8.2.3. Adding Third and Subsequent Regions
To add the third region, and subsequent additional regions, the steps are similar to those for adding
the second region. However, you must repeat certain steps additional times for each additional region:
1. Install CloudPlatform in each additional region. Set the region ID for each region during the
database setup step.
cloudstack-setup-databases cloud:<dbpassword>@localhost --deploy-as=root:<password> -e
<encryption_type> -m <management_server_key> -k <database_key> -r <region_id>
43
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
2. Once the Management Server is running, add your new region to all existing regions by repeatedly
using the Add Region button in the UI. For example, if you were adding region 3:
a. Log in to CloudPlatform in the first region as root administrator (that is, log in to
<region.1.IP.address>:8080/client), and add a region with ID 3, the name of region 3, and the
endpoint <region.3.IP.address>:8080/client.
b. Log in to CloudPlatform in the second region as root administrator (that is, log in to
<region.2.IP.address>:8080/client), and add a region with ID 3, the name of region 3, and the
endpoint <region.3.IP.address>:8080/client.
3. Repeat the procedure in reverse to add all existing regions to the new region. For example, for the
third region, add the other two existing regions:
a. Log in to CloudPlatform in the third region as root administrator (that is, log in to
<region.3.IP.address>:8080/client).
b. Add a region with ID 1, the name of region 1, and the endpoint <region.1.IP.address>:8080/
client.
c. Add a region with ID 2, the name of region 2, and the endpoint <region.2.IP.address>:8080/
client.
4. Copy the account, user, and domain tables from any existing region's database to the new
region's database.
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.
a. First, run this command to copy the contents of the database:
# mysqldump -u root -p<mysql_password> -h <region1_db_host> cloud account user domain
> region1.sql
b. Then run this command to put the data onto the new region's database. For example, for
region 3:
# mysql -u root -p<mysql_password> -h <region3_db_host> cloud < region1.sql
5. Remove project accounts. Run these commands on the region 3 database:
mysql> delete from account where type = 5;
6. Set the default zone as null:
mysql> update account set default_zone_id = null;
7. Restart the Management Servers in the new region.
8.2.4. Deleting a Region
Log in to each of the other regions, navigate to the one you want to delete, and click Remove Region.
For example, to remove the third region in a 3-region cloud:
1. Log in to <region.1.IP.address>:8080/client.
44
Adding a Zone
2. In the left navigation bar, click Regions.
3. Click the name of the region you want to delete.
4. Click the Remove Region button.
5. Repeat these steps for <region.2.IP.address>:8080/client.
8.3. Adding a Zone
Adding a zone consists of three phases:
• Create a mount point for secondary storage on the Management Server.
• Seed the system VM template on the secondary storage.
• Add the zone.
8.3.1. Create a Secondary Storage Mount Point for the New Zone
To be sure the most up-to-date system VMs are deployed in new zones, you need to seed the latest
system VM template to the zone's secondary storage. The first step is to create a mount point for the
secondary storage. Then seed the system VM template.
1. On the management server, create a mount point for secondary storage. For example:
# mkdir -p /mnt/secondary
2. Mount the secondary storage on your Management Server. Replace the example NFS server
name and NFS share paths below with your own.
# mount -t nfs nfsservername:/nfs/share/secondary /mnt/secondary
8.3.2. Prepare the System VM Template
Secondary storage must be seeded with a template that is used for CloudPlatform system VMs.
Note
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.
1. 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 CloudPlatform 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.
45
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
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/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /
mnt/secondary -u http://download.cloud.com/templates/4.2/systemvmtemplate-2013-07-12master-xen.vhd.bz2 -h xenserver -s <optional-management-server-secret-key> -F
• For vSphere:
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /
mnt/secondary -u http://download.cloud.com/templates/4.2/systemvmtemplate-4.2-vh7.ova h vmware -s <optional-management-server-secret-key> -F
• For KVM:
# /usr/share/cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt -m /
mnt/secondary -u http://download.cloud.com/templates/4.2/systemvmtemplate-2013-06-12master-kvm.qcow2.bz2 -h kvm -s <optional-management-server-secret-key> -F
2. 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
3. Repeat these steps for each secondary storage server.
8.3.3. Steps to Add a New Zone
When you add a new zone, you will be prompted to configure the zone’s physical network and add the
first pod, cluster, host, primary storage, and secondary storage.
1. Be sure you have first performed the steps to seed the system VM template.
2. Log in to the CloudPlatform UI as the root administrator. See Section 6.2, “Log In to the UI”.
3. In the left navigation, choose Infrastructure.
4. On Zones, click View More.
5. Click Add Zone. The zone creation wizard will appear.
6. Choose one of the following network types:
• Basic. For AWS-style networking. Provides a single network where each VM instance is
assigned an IP directly from the network. Guest isolation can be provided through layer-3
means such as security groups (IP address source filtering).
• Advanced. For more sophisticated network topologies. This network model provides the most
flexibility in defining guest networks and providing custom network offerings such as firewall,
VPN, or load balancer support.
46
Steps to Add a New Zone
For more information about the network types, see Network Setup.
7. The rest of the steps differ depending on whether you chose Basic or Advanced. Continue with the
steps that apply to you:
• Section 8.3.3.1, “Basic Zone Configuration”
• Section 8.3.3.2, “Advanced Zone Configuration”
8.3.3.1. Basic Zone Configuration
1. After you select Basic in the Add Zone wizard and click Next, you will be asked to enter the
following details. Then click Next.
• Name. A name for the zone.
• DNS 1 and 2. These are DNS servers for use by guest VMs in the zone. These DNS servers
will be accessed via the public network you will add later. The public IP addresses for the zone
must have a route to the DNS server named here.
• Internal DNS 1 and Internal DNS 2. These are DNS servers for use by system VMs in the
zone (these are VMs used by CloudPlatform itself, such as virtual routers, console proxies,
and Secondary Storage VMs.) These DNS servers will be accessed via the management traffic
network interface of the System VMs. The private IP address you provide for the pods must
have a route to the internal DNS server named here.
• Hypervisor. Choose the hypervisor for the first cluster in the zone. You can add clusters with
different hypervisors later, after you finish adding the zone.
• Network Offering. Your choice here determines what network services will be available on the
network for guest VMs.
Network Offering Description
DefaultSharedNetworkOfferingWithSGService If you want to enable security groups for
guest traffic isolation, choose this. (See Using
Security Groups to Control Traffic to VMs.)
DefaultSharedNetworkOffering If you do not need security groups, choose
this.
DefaultSharedNetscalerEIPandELBNetworkOfferingIf you have installed a Citrix NetScaler
appliance as part of your zone network, and
you will be using its Elastic IP and Elastic
Load Balancing features, choose this. With
the EIP and ELB features, a basic zone with
security groups enabled can offer 1:1 static
NAT and load balancing.
• Network Domain. (Optional) If you want to assign a special domain name to the guest VM
network, specify the DNS suffix.
• Public. A public zone is available to all users. A zone that is not public will be assigned to a
particular domain. Only users in that domain will be allowed to create guest VMs in this zone.
2. Choose which traffic types will be carried by the physical network.
47
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
The traffic types are management, public, guest, and storage traffic. For more information about
the types, roll over the icons to display their tool tips, or see Basic Zone Network Traffic Types.
This screen starts out with some traffic types already assigned. To add more, drag and drop traffic
types onto the network. You can also change the network name if desired.
3. Assign a network traffic label to each traffic type on the physical network. These labels must
match the labels you have already defined on the hypervisor host. To assign each label, click the
Edit button under the traffic type icon. A popup dialog appears where you can type the label, then
click OK.
These traffic labels will be defined only for the hypervisor selected for the first cluster. For all other
hypervisors, the labels can be configured after the zone is created.
4. Click Next.
5. (NetScaler only) If you chose the network offering for NetScaler, you have an additional screen to
fill out. Provide the requested details to set up the NetScaler, then click Next.
• IP address. The NSIP (NetScaler IP) address of the NetScaler device.
• Username/Password. The authentication credentials to access the device. CloudPlatform uses
these credentials to access the device.
• Type. NetScaler device type that is being added. It could be NetScaler VPX, NetScaler MPX, or
NetScaler SDX. For a comparison of the types, see About Using a NetScaler Load Balancer.
• Public interface. Interface of NetScaler that is configured to be part of the public network.
• Private interface. Interface of NetScaler that is configured to be part of the private network.
• Number of retries. Number of times to attempt a command on the device before considering
the operation failed. Default is 2.
• Capacity. Number of guest networks/accounts that will share this NetScaler device.
• Dedicated. When marked as dedicated, this device will be dedicated to a single account. When
Dedicated is checked, the value in the Capacity field has no significance – implicitly, its value is
1.
6. (NetScaler only) Configure the IP range for public traffic. The IPs in this range will be used for the
static NAT capability which you enabled by selecting the network offering for NetScaler with EIP
and ELB. Enter the following details, then click Add. If desired, you can repeat this step to add
more IP ranges. When done, click Next.
• Gateway. The gateway in use for these IP addresses.
• Netmask. The netmask associated with this IP range.
• VLAN. The VLAN that will be used for public traffic.
• Start IP/End IP. A range of IP addresses that are assumed to be accessible from the Internet
and will be allocated for access to guest VMs.
7. In a new zone, CloudPlatform adds the first pod for you. You can always add more pods later. For
an overview of what a pod is, see Section 3.3, “About Pods”.
To configure the first pod, enter the following, then click Next:
48
Steps to Add a New Zone
• Pod Name. A name for the pod.
• Reserved system gateway. The gateway for the hosts in that pod.
• Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR
notation.
• Start/End Reserved System IP. The IP range in the management network that CloudPlatform
uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs,
and DHCP. For more information, see System Reserved IP Addresses.
8. Configure the network for guest traffic. Provide the following, then click Next:
• Guest gateway. The gateway that the guests should use.
• Guest netmask. The netmask in use on the subnet the guests will use.
• Guest start IP/End IP. Enter the first and last IP addresses that define a range that
CloudPlatform can assign to guests.
• We strongly recommend the use of multiple NICs. If multiple NICs are used, they may be in a
different subnet.
• If one NIC is used, these IPs should be in the same CIDR as the pod CIDR.
9. In a new pod, CloudPlatform adds the first cluster for you. You can always add more clusters later.
For an overview of what a cluster is, see About Clusters.
To configure the first cluster, enter the following, then click Next:
• Hypervisor. The type of hypervisor software that all hosts in this cluster will run. If the
hypervisor is VMware, additional fields appear so you can give information about a vSphere
cluster. For vSphere servers, we recommend creating the cluster of hosts in vCenter and then
adding the entire cluster to CloudPlatform. See Section 8.5.3, “Add Cluster: vSphere”.
• Cluster name. Enter a name for the cluster. This can be text of your choosing and is not used
by CloudPlatform.
10. In a new cluster, CloudPlatform adds the first host for you. You can always add more hosts later.
For an overview of what a host is, see About Hosts.
Note
When you add a hypervisor host to CloudPlatform, the host must not have any VMs already
running.
Before you can configure the host, you need to install the hypervisor software on the host. You will
need to know which version of the hypervisor software version is supported by CloudPlatform and
what additional configuration is required to ensure the host will work with CloudPlatform. To find
these installation details, see:
• Citrix XenServer Installation and Configuration
• VMware vSphere Installation and Configuration
49
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
• KVM vSphere Installation and Configuration
• Oracle VM (OVM) Installation and Configuration
To configure the first host, enter the following, then click Next:
• Host Name. The DNS name or IP address of the host.
• Username. The username is root.
• Password. This is the password for the user named above (from your XenServer or KVM
install).
• Host Tags. (Optional) Any labels that you use to categorize hosts for ease of maintenance.
For example, you can set this 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.
11. In a new cluster, CloudPlatform adds the first primary storage server for you. You can always add
more servers later. For an overview of what primary storage is, see About Primary Storage.
To configure the first primary storage server, enter the following, then click Next:
• Name. The name of the storage device.
• Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or
SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS. The
remaining fields in the screen vary depending on what you choose here.
8.3.3.2. Advanced Zone Configuration
1. After you select Advanced in the Add Zone wizard and click Next, you will be asked to enter the
following details. Then click Next.
• Name. A name for the zone.
• DNS 1 and 2. These are DNS servers for use by guest VMs in the zone. These DNS servers
will be accessed via the public network you will add later. The public IP addresses for the zone
must have a route to the DNS server named here.
• Internal DNS 1 and Internal DNS 2. These are DNS servers for use by system VMs in the
zone(these are VMs used by CloudPlatform itself, such as virtual routers, console proxies,and
Secondary Storage VMs.) These DNS servers will be accessed via the management traffic
network interface of the System VMs. The private IP address you provide for the pods must
have a route to the internal DNS server named here.
• Network Domain. (Optional) If you want to assign a special domain name to the guest VM
network, specify the DNS suffix.
• Guest CIDR. This is the CIDR that describes the IP addresses in use in the guest virtual
networks in this zone. For example, 10.1.1.0/24. As a matter of good practice you should set
different CIDRs for different zones. This will make it easier to set up VPNs between networks in
different zones.
• Hypervisor. Choose the hypervisor for the first cluster in the zone. You can add clusters with
different hypervisors later, after you finish adding the zone.
50
Steps to Add a New Zone
• Public. A public zone is available to all users. A zone that is not public will be assigned to a
particular domain. Only users in that domain will be allowed to create guest VMs in this zone.
2. Choose which traffic types will be carried by the physical network.
The traffic types are management, public, guest, and storage traffic. For more information about
the types, roll over the icons to display their tool tips, or see Section 3.8.3, “Advanced Zone
Network Traffic Types”. This screen starts out with one network already configured. If you have
multiple physical networks, you need to add more. Drag and drop traffic types onto a greyed-out
network and it will become active. You can move the traffic icons from one network to another; for
example, if the default traffic types shown for Network 1 do not match your actual setup, you can
move them down. You can also change the network names if desired.
3. Assign a network traffic label to each traffic type on each physical network. These labels must
match the labels you have already defined on the hypervisor host. To assign each label, click the
Edit button under the traffic type icon within each physical network. A popup dialog appears where
you can type the label, then click OK.
These traffic labels will be defined only for the hypervisor selected for the first cluster. For all other
hypervisors, the labels can be configured after the zone is created.
(VMware only) If you have enabled Nexus dvSwitch in the environment, you must specify the
corresponding Ethernet port profile names as network traffic label for each traffic type on the
physical network. For more information on Nexus dvSwitch, see Configuring a vSphere Cluster
with Nexus 1000v Virtual Switch. If you have enabled VMware dvSwitch in the environment, you
must specify the corresponding Switch name as network traffic label for each traffic type on the
physical network. For more information, see Configuring a VMware Datacenter with VMware
Distributed Virtual Switch in the Installation Guide.
51
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
4. Click Next.
5. Configure the IP range for public Internet traffic. Enter the following details, then click Add. If
desired, you can repeat this step to add more public Internet IP ranges. When done, click Next.
• Gateway. The gateway in use for these IP addresses.
• Netmask. The netmask associated with this IP range.
• VLAN. The VLAN that will be used for public traffic.
• Start IP/End IP. A range of IP addresses that are assumed to be accessible from the Internet
and will be allocated for access to guest networks.
6. In a new zone, CloudPlatform adds the first pod for you. You can always add more pods later. For
an overview of what a pod is, see Section 3.3, “About Pods”.
To configure the first pod, enter the following, then click Next:
• Pod Name. A name for the pod.
• Reserved system gateway. The gateway for the hosts in that pod.
• Reserved system netmask. The network prefix that defines the pod's subnet. Use CIDR
notation.
52
Steps to Add a New Zone
• Start/End Reserved System IP. The IP range in the management network that CloudPlatform
uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs,
and DHCP. For more information, see Section 3.8.6, “System Reserved IP Addresses”.
7. Specify a range of VLAN IDs to carry guest traffic for each physical network (see VLAN Allocation
Example ), then click Next.
8. In a new pod, CloudPlatform adds the first cluster for you. You can always add more clusters later.
For an overview of what a cluster is, see Section 3.4, “About Clusters”.
To configure the first cluster, enter the following, then click Next:
• Hypervisor. The type of hypervisor software that all hosts in this cluster will run. If the
hypervisor is VMware, additional fields appear so you can give information about a vSphere
cluster. For vSphere servers, we recommend creating the cluster of hosts in vCenter and then
adding the entire cluster to CloudPlatform. See Section 8.5.3, “Add Cluster: vSphere”.
• Cluster name. Enter a name for the cluster. This can be text of your choosing and is not used
by CloudPlatform.
9. In a new cluster, CloudPlatform adds the first host for you. You can always add more hosts later.
For an overview of what a host is, see Section 3.5, “About Hosts”.
Note
When you deploy CloudPlatform, the hypervisor host must not have any VMs already
running.
Before you can configure the host, you need to install the hypervisor software on the host. You will
need to know which version of the hypervisor software version is supported by CloudPlatform and
what additional configuration is required to ensure the host will work with CloudPlatform. To find
these installation details, see:
• Citrix XenServer Installation for CloudPlatform
• VMware vSphere Installation and Configuration
• KVM Installation and Configuration
• Oracle VM (OVM) Installation and Configuration
To configure the first host, enter the following, then click Next:
• 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 or KVM
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
53
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
more information, see HA-Enabled Virtual Machines as well as HA for Hosts, both in the
Administration Guide.
10. In a new cluster, CloudPlatform adds the first primary storage server for you. You can always add
more servers later. For an overview of what primary storage is, see Section 3.6, “About Primary
Storage”.
To configure the first primary storage server, enter the following, then click Next:
• Name. The name of the storage device.
• Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or
SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS. The
remaining fields in the screen vary depending on what you choose here.
NFS • Server. The IP address or DNS name of the storage device.
• Path. The exported path from the server.
• Tags (optional). The comma-separated list of tags for this
storage device. It should be an equivalent set or superset of
the tags on your disk offerings.
The tag sets on primary storage across clusters in a Zone
must be identical. For example, if cluster A provides primary
storage that has tags T1 and T2, all other clusters in the Zone
must also provide primary storage that has tags T1 and T2.
iSCSI • Server. The IP address or DNS name of the storage device.
• Target IQN. The IQN of the target. For example,
iqn.1986-03.com.sun:02:01ec9bb549-1271378984.
• Lun. The LUN number. For example, 3.
• Tags (optional). The comma-separated list of tags for this
storage device. It should be an equivalent set or superset of
the tags on your disk offerings.
The tag sets on primary storage across clusters in a Zone
must be identical. For example, if cluster A provides primary
storage that has tags T1 and T2, all other clusters in the Zone
must also provide primary storage that has tags T1 and T2.
preSetup • Server. The IP address or DNS name of the storage device.
• SR Name-Label. Enter the name-label of the SR that has
been set up outside CloudPlatform.
54
• Tags (optional). The comma-separated list of tags for this
storage device. It should be an equivalent set or superset of
the tags on your disk offerings.
The tag sets on primary storage across clusters in a Zone
must be identical. For example, if cluster A provides primary
storage that has tags T1 and T2, all other clusters in the Zone
must also provide primary storage that has tags T1 and T2.
Adding a Pod
SharedMountPoint • Path. The path on each host that is where this primary
storage is mounted. For example, "/mnt/primary".
• Tags (optional). The comma-separated list of tags for this
storage device. It should be an equivalent set or superset of
the tags on your disk offerings.
The tag sets on primary storage across clusters in a Zone
must be identical. For example, if cluster A provides primary
storage that has tags T1 and T2, all other clusters in the Zone
must also provide primary storage that has tags T1 and T2.
VMFS • Server. The IP address or DNS name of the vCenter
server.
• Path. A combination of the datacenter name and the
datastore name. The format is "/" datacenter name
"/" datastore name. For example, "/cloud.dc.VM/
cluster1datastore".
• Tags (optional). The comma-separated list of tags for this
storage device. It should be an equivalent set or superset of
the tags on your disk offerings.
The tag sets on primary storage across clusters in a Zone
must be identical. For example, if cluster A provides primary
storage that has tags T1 and T2, all other clusters in the Zone
must also provide primary storage that has tags T1 and T2.
11. In a new zone, CloudPlatform adds the first secondary storage server for you. For an overview of
what secondary storage is, see Section 3.7, “About Secondary Storage”.
Before you can fill out this screen, you need to prepare the secondary storage by setting up NFS
shares and installing the latest CloudPlatform System VM template. See Section 8.8, “Adding
Secondary Storage”.
To configure the first secondary storage server, enter the following, then click Next:
• NFS Server. The IP address of the server.
• Path. The exported path from the server.
12. Click Launch.
8.4. Adding a Pod
When you create a new zone, CloudPlatform adds the first pod for you. You can add more pods at any
time using the procedure in this section.
1. Log in to the CloudPlatform UI. See Section 6.2, “Log In to the UI”.
2. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone to
which you want to add a pod.
3. Click the Compute and Storage tab. In the Pods node of the diagram, click View All.
4. Click Add Pod.
55
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
5. Enter the following details in the dialog.
• Name. The name of the pod.
• Gateway. The gateway for the hosts in that pod.
• Netmask. The network prefix that defines the pod's subnet. Use CIDR notation.
• Start/End Reserved System IP. The IP range in the management network that CloudPlatform
uses to manage various system VMs, such as Secondary Storage VMs, Console Proxy VMs,
and DHCP. For more information, see System Reserved IP Addresses.
6. Click OK.
8.5. Adding a Cluster
You need to tell CloudPlatform about the hosts that it will manage. Hosts exist inside clusters, so
before you begin adding hosts to the cloud, you must add at least one cluster.
8.5.1. Add Cluster: KVM or XenServer
These steps assume you have already installed the hypervisor on the hosts and logged in to the
CloudPlatform UI.
1. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in
which you want to add the cluster.
2. Click the Compute tab.
3. In the Clusters node of the diagram, click View All.
4. Click Add Cluster.
5. Choose the hypervisor type for this cluster.
6. Choose the pod in which you want to create the cluster.
7. Enter a name for the cluster. This can be text of your choosing and is not used by CloudPlatform.
8. Click OK.
8.5.2. Add Cluster: OVM
To add a Cluster of hosts that run Oracle VM (OVM):
1. Add a companion non-OVM cluster to the Pod. This cluster provides an environment where the
CloudPlatform System VMs can run. You should have already installed a non-OVM hypervisor on
at least one Host to prepare for this step. Depending on which hypervisor you used:
• For VMWare, follow the steps in Add Cluster: vSphere. When finished, return here and continue
with the next step.
• For KVM or XenServer, follow the steps in Section 8.5.1, “Add Cluster: KVM or XenServer”.
When finished, return here and continue with the next step
2. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in
which you want to add the cluster.
56
Add Cluster: vSphere
3. Click the Compute tab. In the Pods node, click View All. Select the same pod you used in step 1.
4. Click View Clusters, then click Add Cluster.
The Add Cluster dialog is displayed.
5. In Hypervisor, choose OVM.
6. In Cluster, enter a name for the cluster.
7. Click Add.
8.5.3. Add Cluster: vSphere
Host management for vSphere is done through a combination of vCenter and the CloudPlatform UI.
CloudPlatform requires that all hosts be in a CloudPlatform cluster, but the cluster may consist of a
single host. As an administrator you must decide if you would like to use clusters of one host or of
multiple hosts. Clusters of multiple hosts allow for features like live migration. Clusters also require
shared storage.
For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the
entire cluster to CloudPlatform.
8.5.3.1. VMware Cluster Size Limit
The maximum number of hosts in a vSphere cluster is determined by the VMware hypervisor software.
For VMware versions 4.2, 4.1, 5.0, and 5.1, the limit is 32 hosts. CloudPlatform adheres to this
maximum.
Note
Best Practice: It is advisable for VMware clusters in CloudPlatform to be smaller than the VMware
hypervisor's maximum size. A cluster size of up to 8 hosts has been found optimal for most realworld situations.
8.5.3.2. Adding a vSphere Cluster
To add a vSphere cluster to CloudPlatform:
1. Create the cluster of hosts in vCenter. Follow the vCenter instructions to do this. You will create a
cluster that looks something like this in vCenter.
57
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
2. Log in to the UI.
3. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in
which you want to add the cluster.
4. Click the Compute tab, and click View All on Pods. Choose the pod to which you want to add the
cluster.
5. Click View Clusters.
6. Click Add Cluster.
7. In Hypervisor, choose VMware.
8. Provide the following information in the dialog. The fields below make reference to values from
vCenter.
• Cluster Name. Enter the name of the cluster you created in vCenter. For example,
"cloud.cluster.2.2.1"
• vCenter Host. Enter the hostname or IP address of the vCenter server.
• vCenter Username. Enter the username that CloudPlatform should use to connect to vCenter.
This user must have all administrative privileges.
• vCenter Password. Enter the password for the user named above
• vCenter Datacenter. Enter the vCenter datacenter that the cluster is in. For example,
"cloud.dc.VM".
58
Add Cluster: vSphere
If you have enabled Nexus dvSwitch in the environment, the following parameters for dvSwitch
configuration are displayed:
• Nexus dvSwitch IP Address: The IP address of the Nexus VSM appliance.
• Nexus dvSwitch Username: The username required to access the Nexus VSM applicance.
• Nexus dvSwitch Password: The password associated with the username specified above.
There might be a slight delay while the cluster is provisioned. It will automatically display in the
UI
59
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
8.6. Adding a Host
1. Before adding a host to the CloudPlatform configuration, you must first install your chosen
hypervisor on the host. CloudPlatform can manage hosts running VMs under a variety of
hypervisors.
The CloudPlatform Installation Guide provides instructions on how to install each supported
hypervisor and configure it for use with CloudPlatform. See the appropriate section in the
Installation Guide for information about which version of your chosen hypervisor is supported, as
well as crucial additional steps to configure the hypervisor hosts for use with CloudPlatform.
Warning
Be sure you have performed the additional CloudPlatform-specific configuration steps
described in the hypervisor installation section for your particular hypervisor.
2. Now add the hypervisor host to CloudPlatform. The technique to use varies depending on the
hypervisor.
• Section 8.6.1, “Adding a Host (XenServer, KVM, or OVM)”
• Section 8.6.2, “Adding a Host (vSphere)”
8.6.1. Adding a Host (XenServer, KVM, or OVM)
XenServer, KVM, and Oracle VM (OVM) hosts can be added to a cluster at any time.
8.6.1.1. Requirements for XenServer, KVM, and OVM Hosts
Warning
Make sure the hypervisor host does not have any VMs already running before you add it to
CloudPlatform.
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 CloudPlatform
Installation Guide.
8.6.1.1.1. XenServer Host Additional Requirements
If network bonding is in use, the administrator must cable the new host identically to other hosts in the
cluster.
60
Adding a Host (XenServer, KVM, or OVM)
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]
Note
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.
1. Copy the script from the Management Server in /usr/share/cloudstack-common/scripts/vm/
hypervisor/xenserver/cloud-setup-bonding.sh to the master host and ensure it is executable.
2. Run the script:
# ./cloud-setup-bonding.sh
8.6.1.1.2. 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.
8.6.1.1.3. OVM Host Additional Requirements
Before adding a used host in CloudPlatform, as part of the cleanup procedure on the host, be sure to
remove /etc/ovs-agent/db/.
8.6.1.2. Adding a XenServer, KVM, or OVM Host
1. 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 CloudPlatform and what
additional configuration is required to ensure the host will work with CloudPlatform. To find these
installation details, see the appropriate section for your hypervisor in the CloudPlatform Installation
Guide.
2. Log in to the CloudPlatform UI as administrator.
3. In the left navigation, choose Infrastructure. In Zones, click View More, then click the zone in
which you want to add the host.
4. Click the Compute tab. In the Clusters node, click View All.
5. Click the cluster where you want to add the host.
6. Click View Hosts.
61
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
7. Click Add Host.
8. 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.
9. Repeat for additional hosts.
8.6.2. Adding a Host (vSphere)
For vSphere servers, we recommend creating the cluster of hosts in vCenter and then adding the
entire cluster to CloudPlatform. See Add Cluster: vSphere.
8.7. Adding Primary Storage
Warning
When using preallocated storage for primary storage, be sure there is nothing on the storage (ex.
you have an empty SAN volume or an empty NFS share). Adding the storage to CloudPlatform
will destroy any existing data.
When you create a new zone, the first primary storage is added as part of that procedure. You can
add primary storage servers at any time, such as when adding a new cluster or adding more servers
to an existing cluster.
1. Log in to the CloudPlatform UI.
2. In the left navigation, choose Infrastructure. In Zones, click View All, then click the zone in which
you want to add the primary storage.
3. Click the Compute and Storage tab.
4. In the Primary Storage node of the diagram, click View All.
5. Click Add Primary Storage.
6. Provide the following information in the dialog. The information required varies depending on your
choice in Protocol.
• Scope. Indicate whether the storage is available to all hosts in the zone or only to hosts in a
single cluster.
62
Adding Secondary Storage
• Pod. (Visible only if you choose Cluster in the Scope field.) The pod for the storage device.
• Cluster. (Visible only if you choose Cluster in the Scope field.) The cluster for the storage
device.
• Name. The name of the storage device
• Protocol. For XenServer, choose either NFS, iSCSI, or PreSetup. For KVM, choose NFS or
SharedMountPoint. For vSphere choose either VMFS (iSCSI or FiberChannel) or NFS
• Server (for NFS, iSCSI, or PreSetup). The IP address or DNS name of the storage device
• Server (for VMFS). The IP address or DNS name of the vCenter server.
• Path (for NFS). In NFS this is the exported path from the server.
• Path (for VMFS). In vSphere this is a combination of the datacenter name and the datastore
name. The format is "/" datacenter name "/" datastore name. For example, "/cloud.dc.VM/
cluster1datastore".
• Path (for SharedMountPoint). With KVM this is the path on each host that is where this primary
storage is mounted. For example, "/mnt/primary".
• SR Name-Label (for PreSetup). Enter the name-label of the SR that has been set up outside
CloudPlatform.
• Target IQN (for iSCSI). In iSCSI this is the IQN of the target. For example,
iqn.1986-03.com.sun:02:01ec9bb549-1271378984
• Lun # (for iSCSI). In iSCSI this is the LUN number. For example, 3.
• Tags (optional). The comma-separated list of tags for this storage device. It should be an
equivalent set or superset of the tags on your disk offerings
The tag sets on primary storage across clusters in a Zone must be identical. For example, if
cluster A provides primary storage that has tags T1 and T2, all other clusters in the Zone must
also provide primary storage that has tags T1 and T2.
7. Click OK.
8.8. Adding Secondary Storage
Note
Be sure there is nothing stored on the server. Adding the server to CloudPlatform will destroy any
existing data.
When you create a new zone, the first secondary storage is added as part of that procedure. You can
add secondary storage servers at any time to add more servers to an existing zone.
1. To prepare for the zone-based Secondary Staging Store, you should have created and mounted
an NFS share during Management Server installation.
2. Make sure you prepared the system VM template during Management Server installation.
63
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
3. Log in to the CloudPlatform UI as root administrator.
4. In the left navigation bar, click Infrastructure.
5. In Secondary Storage, click View All.
6. Click Add Secondary Storage.
7. Fill in the following fields:
• Name. Give the storage a descriptive name.
• Provider. Choose the type of storage provider (such as S3, Swift, or NFS). NFS can be
used for zone-based storage, and the others for region-wide object storage. S3 can be used
with Amazon Simple Storage Service or any other provider that supports the S3 interface.
Depending on which provider you choose, additional fields will appear. Fill in all the required
fields for your selected provider. For more information, consult the provider's documentation
(such as the S3 or Swift website).
Warning
You can use only a single region-wide object storage account per region. For example, you
can not mix both Swift and S3, or use S3 accounts from multiple different users.
• Create NFS Secondary Staging Store. This box must always be checked.
Warning
Even if the UI allows you to uncheck this box, do not do so. This checkbox and the three
fields below it must be filled in. Even when object storage (such as S3) is used as the
secondary storage provider, an NFS staging storage in each zone is still required.
• Zone. The zone where the NFS Secondary Staging Store is to be located.
• NFS server. The name of the zone's Secondary Staging Store.
• Path. The path to the zone's Secondary Staging Store.
8.8.1. Adding an NFS Secondary Staging Store for Each Zone
Every zone must have at least one NFS store provisioned; multiple NFS servers are allowed per zone.
To provision an NFS Staging Store for a zone:
1. To prepare for the zone-based Secondary Staging Store, you should have created and mounted
an NFS share during Management Server installation.
2. Make sure you prepared the system VM template during Management Server installation.
3. Log in to the CloudPlatform UI as root administrator.
4. In the left navigation bar, click Infrastructure.
64
Initialize and Test
5. In Secondary Storage, click View All.
6. In Select View, choose Secondary Staging Store.
7. Click the Add NFS Secondary Staging Store button.
8. Fill out the dialog box fields, then click OK:
• Zone. The zone where the NFS Secondary Staging Store is to be located.
• NFS server. The name of the zone's Secondary Staging Store.
• Path. The path to the zone's Secondary Staging Store.
8.9. Initialize and Test
After everything is configured, CloudPlatform will perform its initialization. This can take 30 minutes or
more, depending on the speed of your network. When the initialization has completed successfully,
the administrator's Dashboard should be displayed in the CloudPlatform UI.
1. Verify that the system is ready. In the left navigation bar, select Templates. Click on the CentOS
5.5 (64bit) no Gui (KVM) template. Check to be sure that the status is "Download Complete." Do
not proceed to the next step until this status is displayed.
2. Go to the Instances tab, and filter by My Instances.
3. Click Add Instance and follow the steps in the wizard.
a. Choose the zone you just added.
b. In the template selection, choose the template to use in the VM. If this is a fresh installation,
likely only the provided CentOS template is available.
c. Select a service offering. Be sure that the hardware you have allows starting the selected
service offering.
d. In data disk offering, if desired, add another data disk. This is a second volume that will be
available to but not mounted in the guest. For example, in Linux on XenServer you will see /
dev/xvdb in the guest after rebooting the VM. A reboot is not required if you have a PVenabled OS kernel in use.
e. In default network, choose the primary network for the guest. In a trial installation, you would
have only one option here.
f. Optionally give your VM a name and a group. Use any descriptive text you would like.
g. Click Launch VM. Your VM will be created and started. It might take some time to download
the template and complete the VM startup. You can watch the VM’s progress in the
Instances screen.
4.
To use the VM, click the View Console button.
For more information about using VMs, including instructions for how to allow incoming network
traffic to the VM, start, stop, and delete VMs, and move a VM from one host to another, see
Working With Virtual Machines in the Administrator’s Guide.
Congratulations! You have successfully completed a CloudPlatform Installation.
65
Chapter 8. Steps to Provisioning Your Cloud Infrastructure
If you decide to grow your deployment, you can add more hosts, primary storage, zones, pods, and
clusters.
66
Chapter 9.
Service Offerings
In this chapter we discuss compute, disk, and system service offerings. Network offerings are
discussed in the section on setting up networking for users.
9.1. Compute and Disk Service Offerings
A service offering is a set of virtual hardware features such as CPU core count and speed, memory,
and disk size. The CloudPlatform administrator can set up various offerings, and then end users
choose from the available offerings when they create a new VM. A service offering includes the
following elements:
• CPU, memory, and network resource guarantees
• How resources are metered
• How the resource usage is charged
• How often the charges are generated
For example, one service offering might allow users to create a virtual machine instance that is
equivalent to a 1 GHz Intel® Core™ 2 CPU, with 1 GB memory at $0.20/hour, with network traffic
metered at $0.10/GB. Based on the user’s selected offering, CloudPlatform emits usage records
that can be integrated with billing systems. CloudPlatform separates service offerings into compute
offerings and disk offerings. The computing service offering specifies:
• Guest CPU
• Guest RAM
• Guest Networking type (virtual or direct)
• Tags on the root disk
The disk offering specifies:
• Disk size (optional). An offering without a disk size will allow users to pick their own
• Tags on the data disk
9.1.1. Creating a New Compute Offering
To create a new compute offering:
1. Log in with admin privileges to the CloudPlatform UI.
2. In the left navigation bar, click Service Offerings.
3. In Select Offering, choose Compute Offering.
4. Click Add Compute Offering.
5. In the dialog, make the following choices:
• Name: Any desired name for the service offering.
• Description: A short description of the offering that can be displayed to users
67
Chapter 9. Service Offerings
• Storage type: The type of disk that should be allocated. Local allocates from storage attached
directly to the host where the system VM is running. Shared allocates from storage accessible
via NFS.
• # of CPU cores: The number of cores which should be allocated to a system VM with this
offering
• CPU (in MHz): The CPU speed of the cores that the system VM is allocated. For example,
“2000” would provide for a 2 GHz clock.
• Memory (in MB): The amount of memory in megabytes that the system VM should be
allocated. For example, “2048” would provide for a 2 GB RAM allocation.
• Network Rate: Allowed data transfer rate in MB per second.
• Offer HA: If yes, the administrator can choose to have the system VM be monitored and as
highly available as possible.
• Storage Tags: The tags that should be associated with the primary storage used by the system
VM.
• Host Tags: (Optional) Any tags that you use to organize your hosts
• CPU cap: Whether to limit the level of CPU usage even if spare capacity is available.
• isVolatile: If checked, VMs created from this service offering will have their root disks reset
upon reboot. This is useful for secure environments that need a fresh start on every boot and for
desktops that should not retain state.
• Public: Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudPlatform will then prompt for the subdomain's name.
6. Click Add.
9.1.2. Creating a New Disk Offering
To create a new disk offering:
1. Log in with admin privileges to the CloudPlatform UI.
2. In the left navigation bar, click Service Offerings.
3. In Select Offering, choose Disk Offering.
4. Click Add Disk Offering.
5. In the dialog, make the following choices:
• Name. Any desired name for the disk offering.
• Description. A short description of the offering that can be displayed to users
• Storage Type. Type of disk for the VM. Local is attached to the hypervisor host where the VM is
running. Shared is storage accessible via the secondary storage provider.
• Custom Disk Size. If checked, the user can set their own disk size. If not checked, the root
administrator must define a value in Disk Size.
68
Modifying or Deleting a Service Offering
• Disk Size. Appears only if Custom Disk Size is not selected. Define the volume size in GB.
• QoS Type. Three options: Empty (no Quality of Service), hypervisor (rate limiting enforced
on the hypervisor side), and storage (guaranteed minimum and maximum IOPS enforced on
the storage side). If using QoS, make sure that the hypervisor or storage system supports this
feature.
• (Optional) Storage Tags. The tags that should be associated with the primary storage for this
disk. Tags are a comma separated list of attributes of the storage. For example "ssd,blue".
Tags are also added on Primary Storage. CloudPlatform matches tags on a disk offering to tags
on the storage. If a tag is present on a disk offering that tag (or tags) must also be present on
Primary Storage for the volume to be provisioned. If no such primary storage exists, allocation
from the disk offering will fail..
• Public. Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudPlatform will then prompt for the subdomain's name.
6. Click Add.
9.1.3. Modifying or Deleting a Service Offering
Service offerings cannot be changed once created. This applies to both compute offerings and disk
offerings.
A service offering can be deleted. If it is no longer in use, it is deleted immediately and permanently. If
the service offering is still in use, it will remain in the database until all the virtual machines referencing
it have been deleted. After deletion by the administrator, a service offering will not be available to end
users that are creating new instances.
9.2. System Service Offerings
System service offerings provide a choice of CPU speed, number of CPUs, tags, and RAM size, just
as other service offerings do. But rather than being used for virtual machine instances and exposed
to users, system service offerings are used to change the default properties of virtual routers, console
proxies, and other system VMs. System service offerings are visible only to the CloudPlatform root
administrator. CloudPlatform provides default system service offerings. The CloudPlatform root
administrator can create additional custom system service offerings.
When CloudPlatform creates a virtual router for a guest network, it uses default settings which are
defined in the system service offering associated with the network offering. You can upgrade the
capabilities of the virtual router by applying a new network offering that contains a different system
service offering. All virtual routers in that network will begin using the settings from the new service
offering.
9.2.1. Creating a New System Service Offering
To create a system service offering:
1. Log in with admin privileges to the CloudPlatform UI.
2. In the left navigation bar, click Service Offerings.
3. In Select Offering, choose System Offering.
4. Click Add System Service Offering.
69
Chapter 9. Service Offerings
5. In the dialog, make the following choices:
• Name. Any desired name for the system offering.
• Description. A short description of the offering that can be displayed to users
• System VM Type. Select the type of system virtual machine that this offering is intended to
support.
• Storage type. The type of disk that should be allocated. Local allocates from storage attached
directly to the host where the system VM is running. Shared allocates from storage accessible
via NFS.
• # of CPU cores. The number of cores which should be allocated to a system VM with this
offering
• CPU (in MHz). The CPU speed of the cores that the system VM is allocated. For example,
“2000” would provide for a 2 GHz clock.
• Memory (in MB). The amount of memory in megabytes that the system VM should be allocated.
For example, “2048” would provide for a 2 GB RAM allocation.
• Network Rate. Allowed data transfer rate in MB per second.
• Offer HA. If yes, the administrator can choose to have the system VM be monitored and as
highly available as possible.
• Storage Tags. The tags that should be associated with the primary storage used by the system
VM.
• Host Tags. (Optional) Any tags that you use to organize your hosts
• CPU cap. Whether to limit the level of CPU usage even if spare capacity is available.
• Public. Indicate whether the service offering should be available all domains or only some
domains. Choose Yes to make it available to all domains. Choose No to limit the scope to a
subdomain; CloudPlatform will then prompt for the subdomain's name.
6. Click Add.
9.2.2. Changing the Secondary Storage VM Service Offering on a Guest Network
A user or administrator can change the SSVM service offering that is associated with an existing guest
network.
1. Log in to the CloudPlatform UI as an administrator or end user.
2. To change the SSVM service offering, you must first stop all the SSVMs on the network.
For more information, see Section 11.7, “Stopping and Starting VMs”.
3. In the left navigation, click Instances.
4. Choose the VM that you want to work with.
5.
Click the Stop button to stop the VM.
70
Changing the Secondary Storage VM Service Offering on a Guest Network
6.
Click the Change Service button.
7. Select the offering you want.
The Change service dialog box is displayed.
8. Click OK.
9. If you stopped any VMs, restart them.
71
72
Chapter 10.
Setting Up Networking for Users
10.1. Overview of Setting Up Networking for Users
People using cloud infrastructure have a variety of needs and preferences when it comes to the
networking services provided by the cloud. As a CloudPlatform administrator, you can do the following
things to set up networking for your users:
• Set up physical networks in zones
• Set up several different providers for the same service on a single physical network (for example,
both Cisco and Juniper firewalls)
• Bundle different types of network services into network offerings, so users can choose the desired
network services for any given virtual machine
• Add new network offerings as time goes on so end users can upgrade to a better class of service on
their network
• Provide more ways for a network to be accessed by a user, such as through a project of which the
user is a member
10.2. About Virtual Networks
A virtual network is a logical construct that enables multi-tenancy on a single physical network. In
CloudPlatform a virtual network can be shared or isolated.
10.2.1. Isolated Networks
An isolated network can be accessed only by virtual machines of a single account. Isolated networks
have the following properties.
• Resources such as VLAN are allocated and garbage collected dynamically
• There is one network offering for the entire network
• The network offering can be upgraded or downgraded but it is for the entire network
For more information, see Section 16.5.1, “Configuring Isolated Guest Network”.
10.2.2. Shared Networks
A shared network can be accessed by virtual machines that belong to many different accounts.
Network Isolation on shared networks is accomplished by using techniques such as security groups,
which is supported only in Basic zones.
• Shared Networks are created by the administrator
• Shared Networks can be designated to a certain domain
• Shared Network resources such as VLAN and physical network that it maps to are designated by
the administrator
• Shared Networks can be isolated by security groups
• Public Network is a shared network that is not shown to the end users
73
Chapter 10. Setting Up Networking for Users
• Source NAT per zone is not supported when the service provider is virtual router. However, Source
NAT per account is supported with virtual router in a Shared Network.
For information, see Section 16.5.3, “Configuring a Shared Guest Network”.
10.2.3. Runtime Allocation of Virtual Network Resources
When you define a new virtual network, all your settings for that network are stored in CloudPlatform.
The actual network resources are activated only when the first virtual machine starts in the network.
When all virtual machines have left the virtual network, the network resources are garbage collected
so they can be allocated again. This helps to conserve network resources.
10.3. Network Service Providers
Note
For the most up-to-date list of supported network service providers, see the CloudPlatform UI or
call listNetworkServiceProviders.
A service provider (also called a network element) is hardware or virtual appliance that makes a
network service possible; for example, a firewall appliance can be installed in the cloud to provide
firewall service. On a single network, multiple providers can provide the same network service. For
example, a firewall service may be provided by Cisco or Juniper devices in the same physical network.
You can have multiple instances of the same service provider in a network (say, more than one
Juniper SRX device).
If different providers are set up to provide the same service on the network, the administrator can
create network offerings so users can specify which network service provider they prefer (along with
the other choices offered in network offerings). Otherwise, CloudPlatform will choose which provider to
use whenever the service is called for.
10.4. Network Service Providers Support Matrix
10.4.1. Individual
Y = Supported
N = Not Supported
Virtual Router VPC Virtual
Router
BigIP F5 Juniper SRX Citrix
NetScaler
DHCP Y Y N N N
DNS Y Y N N N
User Data Y Y N N N
Source NAT Y Y N Y N
Static NAT Y Y N Y N
74
Support Matrix for an Isolated Network (Combination)
Virtual Router VPC Virtual
Router
Port
Forwarding
Load Balancing Y Y Y N Y
Remote VPN Y N N Y N
Network ACL N Y N N N
Usage
Monitoring
Security Group N N N N N
Firewall Y N N Y N
Y Y N Y N
Y Y Y Y Y
BigIP F5 Juniper SRX Citrix
10.4.2. Support Matrix for an Isolated Network (Combination)
Y = Supported
N = Not Supported
NW
Devices
DHCP DNS User
Data
Source
NAT
Static
NAT
Port
Forwarding
Load
Balancing
Remote
VPN
Network
ACL
Usage
Monitoring
NetScaler
Security
Group
Firewall
Virtual
Router
(VR)
VPC
Virtual
Router
VR
and
F5
Side
by
side
VR
and
NetScaler
Side
by
Side
SRX
and
F5
Side
by
Side
VR VR VR VR VR VR VR VR N Y N Y
VPCVRVPCVRVPCVRVPCVRVPCVRVPCVRVPCVRN VPCVRY N N
VR VR VR VR VR VR F5 VR N Y N Static
NAT /
PF Yes
LB No
VR VR VR VR VR VR NetScalerVR N Y N Static
NAT /
PF Yes
LB No
VR VR VR SRX SRX SRX F5 SRX SRX Y N Static
NAT /
PF Yes
LB No
SRX
and
NetScaler
Side
VR VR VR SRX SRX SRX NetScalerSRX SRX Y N Static
NAT /
PF Yes
75
Chapter 10. Setting Up Networking for Users
NW
Devices
by
Side
SRX
and
F5
Inline
DHCP DNS User
Data
VR VR VR SRX SRX SRX F5 SRX SRX Y N Static
Source
NAT
Static
NAT
Port
Forwarding
Load
Balancing
Remote
VPN
Network
ACL
10.4.3. Support Matrix for Shared Network (Combination)
Y = Supported
N = Not Supported
NW
Devices
Virtual
Router
VR
and
F5
Side
by
side
DHCP DNS User
Data
VR VR VR N N N N N N Y N N
VR VR VR VR VR VR F5 VR N Y N Static
Source
NAT
Static
NAT
Port
Forwarding
Load
Balancing
Remote
VPN
Network
ACL
Usage
Monitoring
Usage
Monitoring
Security
Group
Security
Group
Firewall
LB No
NAT /
PF Yes
LB Yes
Firewall
NAT /
PF Yes
LB No
VR
and
NetScaler
Side
by
Side
SRX
and
F5
Side
by
Side
SRX
and
NetScaler
Side
by
Side
SRX
and
F5
Inline
VR VR VR VR VR VR NetScalerVR N Y N Static
NAT /
PF Yes
LB No
VR VR VR SRX SRX SRX F5 SRX SRX Y N Static
NAT /
PF Yes
LB No
VR VR VR SRX SRX SRX NetScalerSRX SRX Y N Static
NAT /
PF Yes
LB No
VR VR VR SRX SRX SRX F5 SRX SRX Y N Static
NAT /
PF Yes
LB Yes
76
10.4.4. Support Matrix for Basic Zone
Y = Supported
N = Not Supported
Support Matrix for Basic Zone
NW
Devices
Virtual
Router
VR
and
NetScaler
(EIP/
ELB)
DHCP DNS User
Data
VR VR VR N N N N N N Y Y N
VR VR VR N NetScalerN NetScalerN N Y Y N
Source
NAT
Static
NAT
Port
Forwarding
Load
Balancing
Remote
VPN
Network
ACL
Usage
Monitoring
10.5. Network Offerings
Note
For the most up-to-date list of supported network services, see the CloudPlatform UI or call
listNetworkServices.
A network offering is a named set of network services, such as:
• DHCP
• DNS
Security
Group
Firewall
• Source NAT
• Static NAT
• Port Forwarding
• Load Balancing
• Firewall
• VPN
• Optional) Name one of several available providers to use for a given service, such as Juniper for the
firewall
• (Optional) Network tag to specify which physical network to use
When creating a new VM, the user chooses one of the available network offerings, and that
determines which network services the VM can use.
The CloudPlatform administrator can create any number of custom network offerings, in addition
to the default network offerings provided by CloudPlatform. By creating multiple custom network
offerings, you can set up your cloud to offer different classes of service on a single multi-tenant
physical network. For example, while the underlying physical wiring may be the same for two tenants,
tenant A may only need simple firewall protection for their website, while tenant B may be running
77
Chapter 10. Setting Up Networking for Users
a web server farm and require a scalable firewall solution, load balancing solution, and alternate
networks for accessing the database backend.
Note
If you create load balancing rules while using a network service offering that includes an external
load balancer device such as NetScaler, and later change the network service offering to one that
uses the CloudPlatform virtual router, you must create a firewall rule on the virtual router for each
of your existing load balancing rules so that they continue to function.
When creating a new virtual network, the CloudPlatform administrator chooses which network offering
to enable for that network. Each virtual network is associated with one network offering. A virtual
network can be upgraded or downgraded by changing its associated network offering. If you do this,
be sure to reprogram the physical network to match.
CloudPlatform also has internal network offerings for use by CloudPlatform system VMs. These
network offerings are not visible to users but can be modified by administrators.
10.5.1. Creating a New Network Offering
To create a network offering:
1. Log in with admin privileges to the CloudPlatform UI.
2. In the left navigation bar, click Service Offerings.
3. In Select Offering, choose Network Offering.
4. Click Add Network Offering.
5. In the dialog, make the following choices:
• Name. Any desired name for the network offering.
• Description. A short description of the offering that can be displayed to users.
• Network Rate. Allowed data transfer rate in MB per second.
• Guest Type. Choose whether the guest network is isolated or shared.
For a description of this term, see Section 10.2, “About Virtual Networks”.
• Persistent. Indicate whether the guest network is persistent or not. The network that you
can provision without having to deploy a VM on it is termed persistent network. For more
information, see Section 16.28, “Persistent Networks”.
• Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN could be specified
when this offering is used. If you select this option and later use this network offering while
creating a VPC tier or an isolated network, you will be able to specify a VLAN ID for the network
you create.
• VPC. This option indicate whether the guest network is Virtual Private Cloud-enabled. A Virtual
Private Cloud (VPC) is a private, isolated part of CloudPlatform. A VPC can have its own virtual
network topology that resembles a traditional physical network. For more information on VPCs,
see Section 16.27.1, “About Virtual Private Clouds”.
78
Creating a New Network Offering
• Supported Services. Select one or more of the possible network services. For some services,
you must also choose the service provider; for example, if you select Load Balancer, you can
choose the CloudPlatform virtual router or any other load balancers that have been configured
in the cloud. Depending on which services you choose, additional fields may appear in the rest
of the dialog box.
Based on the guest network type selected, you can see the following supported services:
Supported Services Description Isolated Shared
DHCP For more information,
see Section 16.23,
“DNS and DHCP”.
DNS For more information,
see Section 16.23,
“DNS and DHCP”.
Load Balancer If you select Load
Balancer, you
can choose the
CloudPlatform virtual
router or any other
load balancers that
have been configured
in the cloud.
Firewall For more
information, see the
Administration Guide.
Source NAT If you select Source
NAT, you can choose
the CloudPlatform
virtual router or any
other Source NAT
providers that have
been configured in
the cloud.
Supported Supported
Supported Supported
Supported Supported
Supported Supported
Supported Supported
Static NAT If you select Static
NAT, you can choose
the CloudPlatform
virtual router or any
other Static NAT
providers that have
been configured in
the cloud.
Port Forwarding If you select Port
Forwarding, you
can choose the
CloudPlatform virtual
router or any other
Port Forwarding
providers that have
Supported Supported
Supported Supported
79
Chapter 10. Setting Up Networking for Users
Supported Services Description Isolated Shared
been configured in
the cloud.
VPN For more information,
see Section 16.24,
“Remote Access
VPN”.
User Data For more information,
see Section 20.3,
“User Data and Meta
Data”.
Network ACL For more information,
see Section 16.27.4,
“Configuring Network
Access Control List”.
Security Groups For more information,
see Section 16.6.4,
“Adding a Security
Group”.
• System Offering. If the service provider for any of the services selected in Supported Services
is a virtual router, the System Offering field appears. Choose the system service offering that
you want virtual routers to use in this network. For example, if you selected Load Balancer in
Supported Services and selected a virtual router to provide load balancing, the System Offering
field appears so you can choose between the CloudPlatform default system service offering
and any custom system service offerings that have been defined by the CloudPlatform root
administrator.
Supported Supported
Not Supported Supported
Supported Not Supported
Not Supported Supported
For more information, see Section 9.2, “System Service Offerings”.
• LB Isolation: Specify what type of load balancer isolation you want for the network: Shared or
Dedicated.
Dedicated: If you select dedicated LB isolation, a dedicated load balancer device is assigned
for the network from the pool of dedicated load balancer devices provisioned in the zone. If
no sufficient dedicated load balancer devices are available in the zone, network creation fails.
Dedicated device is a good choice for the high-traffic networks that make full use of the device's
resources.
Shared: If you select shared LB isolation, a shared load balancer device is assigned for
the network from the pool of shared load balancer devices provisioned in the zone. While
provisioning CloudPlatform picks the shared load balancer device that is used by the least
number of accounts. Once the device reaches its maximum capacity, the device will not be
allocated to a new account.
• Mode: You can select either Inline mode or Side by Side mode:
Inline mode: Supported only for Juniper SRX firewall and BigF5 load balancer devices. In inline
mode, a firewall device is placed in front of a load balancing device. The firewall acts as the
gateway for all the incoming traffic, then redirect the load balancing traffic to the load balancer
behind it. The load balancer in this case will not have the direct access to the public network.
80
Changing the Network Offering on a Guest Network
Side by Side: In side by side mode, a firewall device is deployed in parallel with the load
balancer device. So the traffic to the load balancer public IP is not routed through the firewall,
and therefore, is exposed to the public network.
• Associate Public IP: Select this option if you want to assign a public IP address to the VMs
deployed in the guest network. This option is available only if
• Guest network is shared.
• StaticNAT is enabled.
• Elastic IP is enabled.
For information on Elastic IP, see Section 16.18, “About Elastic IP”.
• Redundant router capability. Available only when Virtual Router is selected as the Source
NAT provider. Select this option if you want to use two virtual routers in the network for
uninterrupted connection: one operating as the master virtual router and the other as the
backup. The master virtual router receives requests from and sends responses to the user’s
VM. The backup virtual router is activated only when the master is down. After the failover, the
backup becomes the master virtual router. CloudPlatform deploys the routers on different hosts
to ensure reliability if one host is down.
• Conserve mode. Indicate whether to use conserve mode. In this mode, network resources are
allocated only when the first virtual machine starts in the network. When conservative mode is
off, the public IP can only be used for a single service. For example, a public IP used for a port
forwarding rule cannot be used for defining other services, such as StaticNAT or load balancing.
When the conserve mode is on, you can define more than one service on the same public IP.
Note
If StaticNAT is enabled, irrespective of the status of the conserve mode, no port forwarding
or load balancing rule can be created for the IP. However, you can add the firewall rules by
using the createFirewallRule command.
• Tags. Network tag to specify which physical network to use.
• Default egress policy: Configure the default policy for firewall egress rule. Options are Allow
and Deny. Default is Allow if no egress policy is specified, which indicates that all the egress
traffic is accepted when a guest network is created from this offering.
To block the egress traffic for a guest network, select Deny. In this case, when you configure an
egress rules for an isolated guest network, rules are added to allow the specified traffic.
6. Click Add.
10.5.2. Changing the Network Offering on a Guest Network
A user or administrator can change the network offering that is associated with an existing guest
network.
1. Log in to the CloudPlatform UI as an administrator or end user.
81
Chapter 10. Setting Up Networking for Users
2. If you are changing from a network offering that uses the CloudPlatform virtual router to one
that uses external devices as network service providers, you must first stop all the VMs on the
network. See Section 11.7, “Stopping and Starting VMs”.
3. In the left navigation, choose Network.
4. Click the name of the network you want to modify.
5.
In the Details tab, click Edit.
6. In Network Offering, choose the new network offering, then click Apply.
A prompt is displayed asking whether you want to keep the existing CIDR. This is to let you know
that if you change the network offering, the CIDR will be affected.
If you upgrade between virtual router as a provider and an external network device as provider,
acknowledge the change of CIDR to continue, so choose Yes.
7. Wait for the update to complete. Don’t try to restart VMs until the network change is complete.
8. If you stopped any VMs, restart them.
10.5.3. Creating and Changing a Virtual Router Network Offering
To create the network offering in association with a virtual router system service offering:
1. Log in to the CloudPlatform UI as a user or admin.
2. First, create a system service offering, for example: VRsystemofferingHA.
For more information on creating a system service offering, see Section 9.2.1, “Creating a New
System Service Offering”.
3. From the Select Offering drop-down, choose Network Offering.
4. Click Add Network Offering.
5. In the dialog, make the following choices:
• Name. Any desired name for the network offering.
• Description. A short description of the offering that can be displayed to users.
• Network Rate. Allowed data transfer rate in MB per second.
• Traffic Type. The type of network traffic that will be carried on the network.
• Guest Type. Choose whether the guest network is isolated or shared. For a description of these
terms, see Section 10.2, “About Virtual Networks”.
• Specify VLAN. (Isolated guest networks only) Indicate whether a VLAN should be specified
when this offering is used.
• Supported Services. Select one or more of the possible network services. For some services,
you must also choose the service provider; for example, if you select Load Balancer, you can
choose the CloudPlatform virtual router or any other load balancers that have been configured
in the cloud. Depending on which services you choose, additional fields may appear in the rest
of the dialog box. For more information, see Section 10.5.1, “Creating a New Network Offering”
82
Creating and Changing a Virtual Router Network Offering
• System Offering. Choose the system service offering that you want virtual routers to use in
this network. In this case, the default “System Offering For Software Router” and the custom
“VRsystemofferingHA” are available and displayed.
6. Click OK and the network offering is created.
To change the network offering of a guest network to the virtual router service offering:
1. Select Network from the left navigation pane.
2. Select the guest network that you want to offer this network service to.
3. Click the Edit button.
4. From the Network Offering drop-down, select the virtual router network offering you have just
created.
5. Click OK.
83
84
Chapter 11.
Working With Virtual Machines
11.1. About Working with Virtual Machines
CloudPlatform provides administrators with complete control over the life cycle of all guest VMs
executing in the cloud. CloudPlatform provides several guest management operations for end users
and administrators. VMs may be stopped, started, rebooted, and destroyed.
Guest VMs have a name and group. VM names and groups are opaque to CloudPlatform and are
available for end users to organize their VMs. Each VM can have three names for use in different
contexts. Only two of these names can be controlled by the user:
• Instance name – a unique, immutable ID that is generated by CloudPlatform, and can not be
modified by the user. This name conforms to the requirements in IETF RFC 1123.
• Display name – the name displayed in the CloudPlatform web UI. Can be set by the user. Defaults
to instance name.
• Name – host name that the DHCP server assigns to the VM. Can be set by the user. Defaults to
instance name.
Note
You can append the display name of a guest VM to its internal name. For more information, see
Section 11.6, “Appending a Display Name to the Guest VM’s Internal Name”.
Guest VMs can be configured to be Highly Available (HA). An HA-enabled VM is monitored by the
system. If the system detects that the VM is down, it will attempt to restart the VM, possibly on a
different host. For more information, see Section 18.2, “HA-Enabled Virtual Machines”.
In a zone that uses basic networking with EIP enabled, each new VM is by default allocated one public
IP address. When the VM is started, CloudPlatform automatically creates a static NAT between this
public IP address and the private IP address of the VM.
If Elastic IP is in use (with the NetScaler load balancer), the IP address initially allocated to the new
VM is not marked as elastic. The user must replace the automatically configured IP with a specifically
acquired elastic IP, and set up the static NAT mapping between this new IP and the guest VM’s
private IP. The VM’s original IP address is then released and returned to the pool of available public
IPs. Optionally, you can also decide not to allocate a public IP to a VM in an EIP-enabled Basic zone.
For more information on Elastic IP, see Section 16.18, “About Elastic IP”.
CloudPlatform cannot distinguish a guest VM that was shut down by the user (such as with the
“shutdown” command in Linux) from a VM that shut down unexpectedly. If an HA-enabled VM is shut
down from inside the VM, CloudPlatform will restart it. To shut down an HA-enabled VM, you must go
through the CloudPlatform UI or API.
11.2. Best Practices for Virtual Machines
For VMs to work as expected and provide excellent service, follow these guidelines.
85
Chapter 11. Working With Virtual Machines
11.2.1. Monitor VMs for Max Capacity
The CloudPlatform administrator should monitor the total number of VM instances in each cluster,
and disable allocation to the cluster if the total is approaching the maximum that the hypervisor can
handle. Be sure to leave a safety margin to allow for the possibility of one or more hosts failing, which
would increase the VM load on the other hosts as the VMs are automatically redeployed. Consult the
documentation for your chosen hypervisor to find the maximum permitted number of VMs per host,
then use CloudPlatform global configuration settings to set this as the default limit. Monitor the VM
activity in each cluster at all times. Keep the total number of VMs below a safe level that allows for
the occasional host failure. For example, if there are N hosts in the cluster, and you want to allow for
one host in the cluster to be down at any given time, the total number of VM instances you can permit
in the cluster is at most (N-1) * (per-host-limit). Once a cluster reaches this number of VMs, use the
CloudPlatform UI to disable allocation of more VMs to the cluster.
11.2.2. Install Required Tools and Drivers
Be sure the following are installed on each VM:
• For XenServer, install PV drivers and Xen tools on each VM. This will enable live migration and
clean guest shutdown. Xen tools are required in order for dynamic CPU and RAM scaling to work.
• For vSphere, install VMware Tools on each VM. This will enable console view to work properly.
VMware Tools are required in order for dynamic CPU and RAM scaling to work.
To be sure that Xen tools or VMware Tools is installed, use one of the following techniques:
• Create each VM from a template that already has the tools installed; or,
• When registering a new template, the administrator or user can indicate whether tools are installed
on the template. This can be done through the UI or using the updateTemplate API; or,
• If a user deploys a virtual machine with a template that does not have Xen tools or VMware
Tools, and later installs the tools on the VM, then the user can inform CloudPlatform using the
updateVirtualMachine API. After installing the tools and updating the virtual machine, stop and start
the VM.
11.3. VM Lifecycle
Virtual machines can be in the following states:
86
Creating VMs
Once a virtual machine is destroyed, it cannot be recovered. All the resources used by the virtual
machine will be reclaimed by the system. This includes the virtual machine’s IP address.
A stop will attempt to gracefully shut down the operating system, which typically involves terminating
all the running applications. If the operation system cannot be stopped, it will be forcefully terminated.
This has the same effect as pulling the power cord to a physical machine.
A reboot is a stop followed by a start.
CloudPlatform preserves the state of the virtual machine hard disk until the machine is destroyed.
A running virtual machine may fail because of hardware or network issues. A failed virtual machine is
in the down state.
The system places the virtual machine into the down state if it does not receive the heartbeat from the
hypervisor for three minutes.
The user can manually restart the virtual machine from the down state.
The system will start the virtual machine from the down state automatically if the virtual machine is
marked as HA-enabled.
11.4. Creating VMs
Virtual machines are usually created from a template. Users can also create blank virtual machines.
A blank virtual machine is a virtual machine without an OS template. Users can attach an ISO file and
install the OS from the CD/DVD-ROM.
Note
You can create a VM without starting it. You can determine whether the VM needs to be started
as part of the VM deployment. A new request parameter, startVM, is introduced in the deployVm
API to support this feature. For more information, see the Developer's Guide
11.4.1. Creating a VM from a template
1. Log in to the CloudPlatform UI as an administrator or user.
87
Chapter 11. Working With Virtual Machines
2. In the left navigation bar, click Instances.
3. Click Add Instance.
4. Select a zone.
5. Select a template, then follow the steps in the wizard. For more information about how the
templates came to be in this list, see Chapter 13, Working with Templates.
6. Be sure that the hardware you have allows starting the selected service offering.
7. Click Submit and your VM will be created and started.
Note
For security reasons, the internal name of the VM is visible only to the root admin.
11.4.2. Creating a VM from an ISO
Note
(XenServer) Windows VMs running on XenServer require PV drivers, which may be provided
in the template or added after the VM is created. The PV drivers are necessary for essential
management functions such as mounting additional volumes and ISO images, live migration, and
graceful shutdown.
1. Log in to the CloudPlatform UI as an administrator or user.
2. In the left navigation bar, click Instances.
3. Click Add Instance.
4. Select a zone.
5. Select ISO Boot, and follow the steps in the wizard.
6. Click Submit and your VM will be created and started.
7. (Oracle VM only) After ISO installation, the installer reboots into the operating system. Due to a
known issue in OVM, the reboot will place the VM in the Stopped state. In the CloudPlatform UI,
detach the ISO from the VM (so that the VM will not boot from the ISO again), then click the Start
button to restart the VM.
11.4.3. Configuring Usage of Linked Clones on VMware
(For ESX hypervisor in conjunction with vCenter)
VMs can be created as either linked clones or full clones on VMware.
For a full description of clone types, refer to VMware documentation. In summary: A full clone is a
copy of an existing virtual machine which, once created, does not depend in any way on the original
88
Accessing VMs
virtual machine. A linked clone is also a copy of an existing virtual machine, but it has ongoing
dependency on the original. A linked clone shares the virtual disk of the original VM, and retains
access to all files that were present at the time the clone was created.
The use of these different clone types involves some side effects and tradeoffs, so it is to the
administrator's advantage to be able to choose which of the two types will be used in a CloudPlatform
deployment.
A new global configuration setting has been added, vmware.create.full.clone. When the administrator
sets this to true, end users can create guest VMs only as full clones. The default value is true for fresh
installations of CloudPlatform. For customers upgrading from CloudPlatform 2.x or 3.x, the default
value of vmware.create.full.clone is false.
It is not recommended to change the value of vmware.create.full.clone in a cloud with running VMs.
However, if the value is changed, existing VMs are not affected. Only VMs created after the setting is
put into effect are subject to the restriction.
11.5. Accessing VMs
Any user can access their own virtual machines. The administrator can access all VMs running in the
cloud.
To access a VM through the CloudPlatform UI:
1. Log in to the CloudPlatform UI as a user or admin.
2. Click Instances, then click the name of a running VM.
3.
Click the View Console
To access a VM directly over the network:
1. The VM must have some port open to incoming traffic. For example, in a basic zone, a new
VM might be assigned to a security group which allows incoming traffic. This depends on what
security group you picked when creating the VM. In other cases, you can open a port by setting up
a port forwarding policy. See IP Forwarding and Firewalling.
2. If a port is open but you can not access the VM using ssh, it’s possible that ssh is not already
enabled on the VM. This will depend on whether ssh is enabled in the template you picked when
creating the VM. Access the VM through the CloudPlatform UI and enable ssh on the machine
using the commands for the VM’s operating system.
3. If the network has an external firewall device, you will need to create a firewall rule to allow
access. See IP Forwarding and Firewalling.
11.6. Appending a Display Name to the Guest VM’s Internal
Name
Every guest VM has an internal name. The host uses the internal name to identify the guest VMs.
CloudPlatform gives you an option to provide a guest VM with a display name. You can add this
display name to the internal name so that it is displayed in contexts where the internal name is shown,
such as in vCenter. This feature is intended to make the correlation between instance names and
internal names easier in large data center deployments.
To append display names to VM internal names, set the global configuration parameter
vm.instancename.flag to true. The default value of this parameter is false.
89
Chapter 11. Working With Virtual Machines
The default format of the internal name is i-<user_id>-<vm_id>-<instance.name>, where
instance.name is a global parameter. When vm.instancename.flag is set to true, if a display name is
provided during the creation of a guest VM, the display name is appended to the internal name of the
guest VM on the host. This changes the internal name format to i-<user_id>-<vm_id>-<displayName>.
The following table explains how a VM name is displayed in different scenarios.
User-Provided
Display Name
Yes True Display name i-<user_id>-
No True UUID i-<user_id>-
Yes False Display name i-<user_id>-
No False UUID i-<user_id>-
vm.instancename.flagHostname on theVMName on
vCenter
<vm_id>displayName
<vm_id><instance.name>
<vm_id><instance.name>
<vm_id><instance.name>
Internal Name
i-<user_id><vm_id>displayName
i-<user_id><vm_id><instance.name>
i-<user_id><vm_id><instance.name>
i-<user_id><vm_id><instance.name>
11.7. Stopping and Starting VMs
Once a VM instance is created, you can stop, reset, or delete it as needed. In the CloudPlatform UI,
click Instances, select the VM, and use the Stop, Start, Reset, Reboot, and Destroy buttons.
Reseting leads to restarting a VM. You can reset when a VM is either running or stopped.
11.8. Assigning VMs to Hosts
At any point in time, each virtual machine instance is running on a single host. How does
CloudPlatform determine which host to place a VM on? There are several ways:
• Automatic default host allocation. CloudPlatform can automatically pick the most appropriate host to
run each virtual machine.
• Instance type preferences. CloudPlatform administrators can specify that certain hosts should have
a preference for particular types of guest instances. For example, an administrator could state that
a host should have a preference to run Windows guests. The default host allocator will attempt to
place guests of that OS type on such hosts first. If no such host is available, the allocator will place
the instance wherever there is sufficient physical capacity.
• Vertical and horizontal allocation. Vertical allocation consumes all the resources of a given host
before allocating any guests on a second host. This reduces power consumption in the cloud.
Horizontal allocation places a guest on each host in a round-robin fashion. This may yield better
performance to the guests in some cases.
• End user preferences. Users can not control exactly which host will run a given VM instance, but
they can specify a zone for the VM. CloudPlatform is then restricted to allocating the VM only to one
of the hosts in that zone.
90
Loading...