We will first provide an overview of adding a basic type of Zone setup.
On selecting the Basic Zone type, move on to the next screen and provide details about the zone that we are creating. The configuration will involve the setting up and configuration of the zone properties such as:
• Zone type
• Network configuration of the zone—Public Network and traffic, configuration of one Pod, Guest traffic, and storage traffic
• Addition of resources to the zone—one cluster, one host, one primary, and one secondary storage
The parameters provided for adding a new basic zone are as follows: • Name: This is the name of the new Zone that we are creating.
• DNS1: This is the primary DNS server that will be available in the Zone. • DNS2: This is an optional field. This is the second DNS server that will be
• These DNS servers are used by guest virtual machines in the zone and should be accessible by the public network that will be added to the zone at a later stage. The zone will also have some public addresses; the DNS servers must be accessible from these public addresses.
• Internal DNS1: This is the address of the primary internal DNS server. • Internal DNS2: This is the address of the secondary internal DNS server,
which will be used by the cloud only when the primary internal DNS server is down.
• These internal DNS servers will be used by the system virtual machines in the zone. This DNS server will be accessed by the management traffic of the cloud. These DNS servers must be accessible by the private IP addresses in the pods of the zone that we are adding.
• Hypervisor: Here we have the option of choosing the type of hypervisor that will be used in this Zone. We have the option to choose from the list, like XenServer, KVM, VMware, Baremetal, KVM, or OVM. The hypervisor that we select here defines the zone and is unique for the complete zone, i.e. only host with the same hypervisor can be added to this zone. If we need to add hosts with another type of hypervisor, we need to create a different zone for that hypervisor type.
• Network offering: In this list are available various network offerings that we have created in the previous section of this chapter. The choice of the network offering will determine the type of the network services that will be available in the Zone for the guest virtual machines. These network offerings are defined in the network offering tab of the service offering page. The options available here are:
° DefaultNetworkofferingWithSGServer: This network offering has security groups enabled for the guest virtual machines which will provide guest isolation to them. This network offering has other network services such as UserData, DHCP, and DNS.
° DefaultSharedNetworkOffering: This network offering doesn't offer the support for the security group, so if you don't want the security group, choose this offering.
° DefaultSharedNetscalerEIPandELBNetworkOffering: This
network offering should be chosen when you have a Citrix NetScaler appliance as a part of the zone. This enables the usage of the Elastic IP address and Elastic Load balancer features provided by that appliance. You can create a basic zone with security groups enabled to offer 1:1 static NAT and load balancing.
• Network Domain: The network domain can also be assigned here if you want a special domain name to be assigned to the guest VM. This DNS suffix will appear in the hostname of the guest VMs.
• Public: This option specifies the scope of availability of the Zone to the users in the cloud. If it is selected, then all the users across all the domains will be allowed to create guest VMs in this zone. Otherwise, you can limit this zone scope to a particular domain, in this case only users belonging to that domain will be able to create guest VMs in this zone.
After all the options have been filled out accordingly, we will move to the next screen where we have to configure the physical network corresponding to the physical network interface card of the hypervisor.
You will have to set up one physical network which will carry multiple traffics. We can add the network traffic that will flow across this network. The network traffic can be any combination of the three types of network:
• Management Traffic: This is the traffic between the CloudStack's internal resources. All the communication from any resources that communicates to the Management Server such as Hosts and System VMs is categorized as Management traffic.
• Traffic between CloudStack's guest VMs: The communication of guest VMs in the CloudStack is categorized as this kind of traffic.
• Storage traffic: All the traffic between the secondary storage VM and the secondary storage such as VM templates and snapshots is categorized as the storage traffic.
We can edit the labels to be used for these individual traffics by clicking on the Edit
button. These labels are text strings that the CloudStack matches for different kinds of traffic with the traffic label that is already defined on the hypervisor host. These labels are defined just for the first hypervisor host that will be selected for the first cluster, for any other hosts, labels can be added once the zone has been created. The users can also select different Network offerings such as
DefaultSharedNetscalerEIPandELBNetworkOffering, in which case the users will have two extra screens to fill in that consists of the NetScaler device configuration. This network offering has various services supported with it as User Data, DNS, load balancer, and Elastic IP, and these options are for configuration of the network carrying traffic between end users' virtual machine and internet—public traffic. In this case you must enter the configuration details for the NetScaler device, as shown in the following screenshot:
The options displayed while adding a NetScaler device are as follows: • IP address: The IP address of the NetScaler device (NSIP) • Username: Username for the login of NetScaler device
• Password: Password corresponding to the username specified above for the Netscaler device
• Type: The NetScaler device type which you are adding, It is the list of values such as NetScaler VPX, NetScaler MPX, or NetScaler SDX
• Public Interface: The interface of the NetScaler which is a part of the public network
• Private Interface: The interface of the NetScaler device which is configured to be a part of the private network
• Number of retries: This is the number of times a command should be retried before it is considered to have failed
• Capacity: This specifies the number of guest networks/accounts that will share this NetScaler device
• Dedicated: This option makes the device dedicated to a single account. If this option is selected, the value in the capacity field is taken to be "1" irrespective of what is specified
After you have configured the NetScaler device details, you will be asked about the details of the public traffic—the IP range for the public traffic is to be provided. These IP addresses will be used to provide static NAT capability. These capabilities are enabled while selecting the Network offering for NetScaler with EIP and ELB. The screen on the next page looks like this:
The options for setting up the public traffic in the network setup of a basic zone are: • Gateway: The address of gateway to be used for these IP addresses
• Netmask: The netmask associated with this IP range • VLAN: The VLAN which is to be used for public traffic
• Start IP/End IP: This is the range of the IP addresses that are Internet facing and are to be allocated for access to the guest VMs so that they can access the Internet
After we have configured the physical network and NetScaler device configuration, the next step is to add pods to this zone. A zone can contain multiple pods. For more details, refer to Chapter 1, Apache CloudStack Architecture.
We will have to add the first Pod where we will configure a range of reserved IP addresses for CloudStack's internal management traffic which should be unique for each zone in the cloud. Later, after the creation of zone, we can add more pods.
• Name: This is the name of the Pod which we are adding.
• Reserved System Gateway: This is the gateway for the hosts in this Pod. • Reserved System Netmask: This is the network prefix which will define this
Pod's subnet. We have to define an IP range here using CIDR notation.
• Start/End Reserved System IP: This is the IP range which will be used for the Management traffic. This IP range will be used by CloudStack's Management server for managing various System VMs, secondary storage VMs, Console Proxy VMs, and DHCP over the Management traffic.
After adding the first Pod by providing the required values, we will proceed to configure the guest traffic. Clicking on the Next button brings up the next screen for configuring guest traffic:
The Storage traffic options are:
• Guest Gateway: This is the gateway that the guests use.
• Guest Netmask: This is the netmask of the subnet which will be used by the guests.
• Guest Start/End IP: This is the first and the last IP addresses of the IP address range which will be assigned to the guests by CloudStack. CloudStack recommends using multiple NICs which allow the NICs to be in different subnets. In case you use only one NIC, these IP addresses must be in the CIDR range of the Pod.
After the guest traffic has been set up, we will add the first clusters of the hypervisor type we have defined earlier. On clicking the Next button, we get the following screen:
The Cluster details are entered in the options given as follows:
• Hypervisor: This is the type of the hypervisor which we selected earlier. This is the hypervisor which all the hosts in the cluster will use. Different fields may need to be filled in based on the selection of the type of hypervisor. In case we are using VMware as the hypervisor, it is recommended to create the cluster in vCenter and then add it here.
• Name: This is the name of the first cluster that we are configuring here. This is the first cluster that we are adding to the cloud, if you want to add more clusters, you can do that after the creation of the zone. After this first cluster is added, we have to add hosts to the zone. A cluster can have multiple hosts of same hypervisor type which hosts the guest VMs. We will add the first host here and for any more addition of hosts, we can do that after the creation of this zone. The host we are adding must have a hypervisor running on it with an IP address configured and must be connected to the Cloudstack Management server.
The host configuration values are provided in the options given as follows: • Hostname: This is the DNS name of the host.
• Username: This is the username of the host, usually "root".
• Password: This is the password for the user specified in the field above. • Host Tags (optional): This can be any tag which will be used to categorize the
This will add the first host to the Zone. The next screen on clicking Next lets us add the primary storage server. Each host has at least one primary storage server.
The options for adding primary storage in the zone are:
• Name: This is the name of the first primary storage server that we are adding here.
• Protocol: This field is dependent upon the type of hypervisor we are using. In the case of XenServer, we have the option to choose from NFS, iSCSI, or PreSetup. In case of KVM, we can choose the protocol for the Primary storage server as NFS or SharedMountPoint. For vSphere, we can use either VMFS, which can be iSCSI or FiberCannel or NFS. Depending upon the selection of this field there can be other fields in this screen.
If we select an NFS server, the path is the location of the Primary storage on the server.
Next we have to add the secondary storage to the zone. The secondary storage can be accessed by all the hosts in all the cluster of the Zones and is used to store templates, ISO images, snapshots, and so on. On moving to the next screen we get:
The options include:
• NFS server: This is the NFS server hosting the secondary storage. • Path: This is the exported path from the server.
After the addition of secondary storage, we are done with the configuration of the zone, and we can launch it.
This was the configuration of the Basic Zone type. Let's see how it is different from the Advanced Zone configuration and what extra configuration inputs are required in order to create a zone with advanced network topologies.