The Infrastructure layer is the base layer and comprises of all the hardware resources upon which IT is built upon. These include computing resources, storage resources, network resources, and so on.

Storage

Like the Compute capacity, we need storage which is accessible to the Compute layer.

The Storage in cloud environments is pooled just like the Compute and accessed through the virtualization layer. Certain types of services just offer storage as a service where the storage can be programmatically accessed to store and retrieve objects.

Pooled, virtualized storage is enabled through technologies such as Network Attached Storage (NAS) and Storage Area Network (SAN) which helps in allowing the infrastructure to allocate storage on demand that can be based on policy, that is, automated.

The storage provisioning using such technologies helps in providing storage capacity on demand to users and also enables the addition or removal of capacity as per the demand. The cost of storage can be differentiated according to the different levels of performance and classes of storage.

Typically, SAN is used for storage capacity in the cloud where statefulness is required. Direct-attached Storage (DAS) can be used for stateless workloads that can drive down the cost of service. The storage involved in cloud architecture can be redundant and prevent the single point of failure. There can be multiple paths for the access of disk arrays to provide redundancy in case connectivity failures.

The storage arrays can also be configured in a way that there is incremental backup of the allocated storage. The storage should be configured such that health information of the storage units is updated in the system monitoring service, which ensures that the outage and its impact are quickly identified and appropriate action can be taken in order to restore it to its normal state.

Networks and security

Network configuration includes defining the subnets, on-demand allocation of IP addresses, and defining the network routing tables to enable the flow of data in the network. It also includes enabling high availability services such as load balancing. Whereas the security configuration aims to secure the data flowing in the network that includes isolation of data of different tenants among each other and with the management data of cloud using techniques such as network isolation and security groups.

Networking in the cloud is supposed to deal with the isolation of resources between multiple tenants as well as provide tenants with the ability to create isolated components. Network isolation in the cloud can be done using various techniques of network isolation such as VLAN, VXLAN, VCDNI, STT, or other such techniques.

Applications are deployed in a multi-tenant environment and consist of components that are to be kept private, such as a database server which is to be accessed only from selected web servers and any other traffic from any other source is not permitted to access it. This is enabled using network isolation, port filtering, and security groups. These services help with segmenting and protecting various layers of application deployment architecture and also allow isolation of tenants from each other.

The provider can use security domains, layer 3 isolation techniques to group various virtual machines. The access to these domains can be controlled using providers' port filtering capabilities or by the usage of more stateful packet filtering by implementing context switches or firewall appliances. Using network isolation techniques such as VLAN tagging and security groups allows such configuration. Various levels of virtual switches can be configured in the cloud for providing isolation to the different networks in the cloud environment.

Networking services such as NAT, gateway, VPN, Port forwarding, IPAM systems, and access control management are used in the cloud to provide various networking services and accessibility. Some of these services are explained as follows:

• NAT: Network address translation can be configured in the environment to allow communication of a virtual machine in private network with some other machine on some other network or on the public Internet. A NAT device allows the modification of IP address information in the headers of IP packets while they are transformed from a routing device. A machine in a private network cannot have direct access to the public network so in order for it to communicate to the Internet, the packets are sent to a routing device or a virtual machine with NAT configured which has direct access to the Internet. NAT modifies the IP packet header so that the private IP address of the machine is not visible to the external networks.

• IPAM System/DHCP: An IP address management system or DHCP server helps with the automatic configuration of IP addresses to the virtual machines according to the configuration of the network and the IP range allocated to it. A virtual machine provisioned in a network can be assigned an IP address as per the user or is assigned an IP address from the IPAM. IPAM stores all the available IP addresses in the network and when a new IP address is to be allocated to a device, it is taken from the available IP pool, and when a device is terminated or releases the IP address, the address is given back to the IPAM system.

• Identity and access management: A access control list describes the permissions of various users on different resources in the cloud. It is important to define an access control list for users in a multi-tenant environment. It helps in restricting actions that a user can perform on any resource in the cloud. A role-based access mechanism is used to assign roles to users' profile which describes the roles and permissions of users on different resources.

Use of switches in cloud

A switch is a LAN device that works at the data link layer (layer 2) of the OSI model and provides multiport bridge. Switches store a table of MAC addresses and ports. Let us see the various types of switches and their usage in the cloud environment:

• Layer 3 switches: A layer-3 switch is a special type of switch which operates at layer 3—the Network layer of the OSI model. It is a high performance device that is used for network routing. A layer-3 switch has a IP routing table for lookups and it also forms a broadcast domain. Basically, a layer-3 switch is a switch which has a router's IP routing functionality built in.

  A layer-3 switch is used for routing and is used for better performance over routers. The layer-3 switches are used in large networks like corporate networks instead of routers. The performance of the layer-3 switch is better than that of a router because of some hardware-level differences. It supports the same routing protocols as network routers do. The layer-3 switch is used above the layer-2 switches and can be used to configure the routing configuration and the communication between two different VLANs or different subnets.

• Layer 4-7 switches: These switches use the packet information up to OSI layer 7 and are also known as content switches, web-switches, or application switches. These types of switches are typically used for load balancing among a group of servers which can be performed on HTTP, HTTPS, VPN, or any TCP/IP traffic using a specific port. These switches are used in the cloud for allowing policy-based switching—to limit the different amount of traffic on specific end-user switch ports. It can also be used for prioritizing the traffic of specific applications. These switches also provide forwarding decision making like NAT services and also manages the state of individual sessions from beginning to end thus acting like firewalls. In addition, these switches are used for balancing traffic across a cluster of servers as per the configuration of the individual session information and status. Hence these types of switches are used above layer-3 switches or above a cluster of servers in the environment. They can be used to forward packets as per the configuration such as transferring the packets to a server that is supposed to handle the requests and this packet forwarding configuration is generally based on the current server loads or sticky bits that binds the session to a particular server.

• Layer-3 traffic isolation provides traffic isolation across layer-3 devices. It's referred to as Virtual Routing and Forwarding (VRF). It virtualizes the routing table in a layer-3 switch and has set of virtualized tables for routing. Each table has a unique set of forwarding entries. Whenever traffic enters, it is forwarded using the routing table associated with the same VRF. It enables logical isolation of traffic as it crosses a common physical network infrastructure. VRFs provide access control, path isolation, and shared services. Security groups are also an example of layer-3 isolation capabilities which restricts the traffic to the guests based on the rules defined. The rules are defined based on the port, protocol, and source/destination of the traffic.

• Virtual switches: The virtual switches are software program that allows one guest VM to communicate with another and is similar to the Ethernet switch explained earlier. Virtual switches provide a bridge between the virtual NICs of the guest VMs and the physical NIC of the host. Virtual switches have port groups on one side which may or may not be connected to the different subnets. There are various types of virtual switches used with various virtualization technologies such as VMware Vswitch, Xen, or Open Vswitch. VMware also provides a distributed virtual switch which spans multiple hosts. The virtual switches consists of port groups at one end and an uplink at the other. The port groups are connected to the virtual machines and the uplink is mapped to the physical NIC of the host. The virtual switches function as a virtual switch over the hypervisor layer on the host.

The Management layer in a cloud computing space provides management capabilities to manage the cloud setup.

It provides features and functions such as reporting, configuration for the automation of tasks, configuration of parameters for the cloud setup, patching, and monitoring of the cloud components.

The CloudStack deployment model covers the basic components of CloudStack, using which CloudStack provides all the functionalities; it also covers the logical segregation of resources to help better manage them.

Zones

Zones are the highest level of hierarchy in which the datacenter of an organization is logically partitioned to provide physical isolation and redundancy. The zone may be a complete datacenter that has a geographic location with its own power supply and network uplinks. The zone can also be distributed across various geographic locations. Typically a datacenter contains a single zone but it can also contain multiple zones. The logical division into zones enables the instances and the data stores at a specified location to be compliant with an organization's data storage policies, and other compliance policies, and so on.

A zone is divided into various other logical units. A zone comprises of following:

• At least one or more pods. A pod is the second level of hierarchical unit discussed later which consists of one or more clusters. We will discuss this in detail next.

• Secondary storage, this storage is shared by all the pods in a zone.

End users can select a zone while requesting a guest VM.

A zone can be associated with domains; a zone can be public or private. A public zone is visible to all the users whereas private zones can be reserved for some specific domain which means that the users that belong to that domain or its subdomain have the permissions to create guest VMs in that private zone.

The pod(s) in a zone consists of one or more clusters which in turn contains host(s).

The hosts in a zone can access and be accessed by other hosts in that zone if there's no restriction from any firewall and a flat network is defined, but if a host in a zone tries to access hosts in other zones, they have to follow VPN tunnels which are configured with firewall rules. Among all the other traffic, only key management traffic is allowed in between the hosts in different clusters.

The zones must be configured by the cloud administrator with the number of pods in the zone, number of clusters in a pod, and number of hosts in each of the clusters. The clusters also contain primary storage servers so the cloud administrator must also decide upon the number and the capacity of primary storage servers that are to be placed in each of the clusters. As a minimum configuration, each zone must have at least one pod, each pod must have at least one cluster with at least one host, the cluster must have at least one primary storage. The capacity of the secondary storage that is used by all the hosts in all the pods of a zone is also to be configured by the administrator.

Once these components are configured they are consumed by the management server to provide cloud services to the customers. A zone is hypervisor specific—a zone will only consist of hosts with the same hypervisor only. Hosts with different hypervisors are added to different zones.

Pods

A pod is the second level of hierarchy in the deployment of the CloudStack. A zone is further logically divided into one or more entities known as pod. A pod can be assumed to be like a physical rack in a datacenter in which all the hosts reside in the same network subnet. The pod defines the management subnet of the system VMs (discussed later), this network is used by the CloudStack management server communication. A pod contains one or more clusters and a cluster in turn contains one or more hosts. All the hosts that are inside a pod are configured to be in the same subnet. There are one or more primary storage servers in a pod. A pod is invisible to users—the users don't know which pod their machine is being provisioned in to. The logical division into pods is for administrative purposes only. As with the zone, all the hosts in a pod will have hosts with same hypervisor type as defined during the creation of zone and these hosts are in the same subnet.

Clusters

A cluster is the third level of hierarchical division in the deployment of CloudStack inside pods. The hosts are grouped into a logical group called clusters. This cluster can be a XenServer server pool, VMware cluster that is preconfigured in the VCenter, or a set of KVM servers.

Hosts within a cluster are accessible to each other and guests residing on a host in a cluster can also be "live migrated" to another host in the same cluster using a shared storage device. The live migration occurs without any interruption to the users and thus provides high availability option. In order to support live migration of VMs between hosts in a cluster, those hosts should have similar properties such as using the same hypervisor version and the same hardware. They should also have access to the same primary storage servers that are shared among the hosts in a cluster. A cluster contains at least one primary storage server.

In this section we will discuss the various storage options available in the CloudStack system.

This storage space is used to store the templates, ISO images and snapshots that can be used to deploy IT infrastructure using CloudStack. Every zone has at least one secondary storage server and this secondary storage(s) is shared by all the Pods in that zone.

CloudStack also provides the functionality to automatically replicate the secondary storage across zones so that one can implement a disaster recovery solution by backing up the application across zones, allowing easy recovery from a zone failure. Thus, CloudStack provides a common storage solution across the cloud. Unlike primary storage, secondary storage only uses Network File System (NFS) as it is to be accessed by all the hosts in the clusters across the zones irrespective of the hypervisors on the hosts.

The secondary storage is used to store templates that are basically OS images that are used to boot VMs with some more additional configuration information and installed applications.

Secondary storage also stores ISO images that are disk images used for booting operating system and disk volume snapshot, used for backing up the data of VMs for data recovery or for creating new templates. These items are available to all the hosts in one zone.

A secondary storage device can be an OpenStack object (swift) with at least 100 GB of space, an NFS storage appliance or a Linux NFS server. The secondary storage and the VMs that it is serving must be located in the same zone and should be accessible by all the hosts in that zone. The scalability of a zone is dependent upon the capacity of the secondary storage device. A disk with high read:write ratio, larger disk drives, and lower IOPS than primary storage is best suited for secondary storage.

The administrators can change the secondary storage server afterwards or it can be replaced with a new one after implementation; to achieve this one just needs to copy all the files from the old one to the new one.

The CloudStack management server helps us to manage the IT infrastructure as defined in the previous sections. The CloudStack management server provides a single point of configuration for the cloud. Basic functionalities of the management server include:

The management server provides an easy to use web user interface for administrators and the users who can leverage it to manage and request IT infrastructure on demand. It also provides the users and administrators with CloudStack APIs. The management server can be configured to be highly available to prevent single point of failure. This is achieved by deploying it in a multi-node configuration and placing it behind a load balancer so that multiple requests must be served by multiple nodes acting as the management server. High availability can be ensured for the CloudDB by setting up a MySQL cluster. Setting up the CloudStack in this fashion, with a highly available management server and highly available CloudDB provides no single point of failure.

Even though the management server is configured in a multi-node configuration, the operation of the guest VMs is not impacted due to its outage, but the creation of new VMs and management of existing VMs through the management server cannot be done and all the interfaces along with dynamic load balancing and HA will also stop working. The CloudStack Management server is comprised of various parts which handle the functionalities of the cloud.

The basic units of CloudStack management server are:

On a more granular level, the basic functions of the management server are divided among the server's various modules, which are described as follows.

The kernel is made up of several different components performing tasks in silos. It is the central component for distributing, integrating, and handling the tasks and operations going in and out. The kernel distributes the tasks among the various other components of the CloudStack and drives long-running VM operations, performs sync between the resources, and the database, generates events that are caught by different components and performs actions based on it.

Below all the components lie some more core components that provide the end-to-end interaction possible in CloudStack. Some of these are discussed as follows:

The CloudStack management server is the core component that is responsible for managing the actions that make the whole deployment a success. Let's take a close look into the process flow within the CloudStack—when a new request comes in, how is it fulfilled?

The CloudDB is the primary MySQL database that is used by management server in the CloudStack deployment for storing all the configuration information. The CloudDB can be installed on the same server or on a different server. The CloudDB can also be set up as a MySQL cluster for high availability. The CloudStack management server communicates with the master database and the replicas are in sync with the master continuously. The administrator must configure the MySQL database or CloudDB with a username and password for security.

The administrator can also provide MySQL replication in order to provide manual failover in case of database failure.

CloudDB is a critical component for the working of CloudStack as it contains information about the offering, hosts' profiles, accounts credentials, configuration information, network information, and so on. The database is accessed for information on an on-demand basis, which shows the criticality of the management server and database and the need to configure them properly.

There are two main types of network configurations that can be deployed using CloudStack: the basic and advanced types.

The basic type is similar to AWS level 3 isolation using security groups. The security groups ensure the isolation and the egress and ingress of the traffic. The IPAM system manages the IP addresses and tenants don't usually get a contiguous IP address or subnet, the assignment of IP addresses to tenants is basically random from the IPAM system. This configuration has the capability to scale to configure millions of virtual machines on thousands of hosts.

The advanced type offers full level 3 subnets where security and isolation are provided using VLANs, Stateless transport tunneling (STT), and Generic Routing Encapsulation (GRE). Other features such as NAT, VPN, and so on can also be configured.

Networking using CloudStack virtual router

The virtual router is used by CloudStack to provide various networking services. The machines connected to guest virtual networks are connected to the outside world using public IP addresses through the virtual router and communicate with the other guests using the virtual router. All the communications from these servers behind the virtual router to the outside world are routed by the virtual router. The CloudStack virtual router is a device which is actually a virtual machine that provides networking services such as DHCP server which assigns IP addresses to the machines behind it, a DNS server which manages the host name to IP address mapping of the machines, NAT, a VPN gateway and many other.

There can be multiple guest virtual networks in the CloudStack environment. These networks are created using some network offering. Most of the networking services that are provided in the network offerings used in the creation of a network are provided by the CloudStack virtual router. The machines can have more than one network interface cards that can be assigned multiple IP addresses to the guest machines. This means that a virtual machine connected to one of the guest virtual network can have two NICs attached to it. One of the NICs has a private IP address and the other is connected to another guest virtual network of different subnet facilitated by another CloudStack virtual router.

The machine with two NICs, one attached to the guest virtual network 1 can be used to host the web server which has incoming public traffic of requests and the other NIC dedicated to the communication to databases server which can be present on the another VM attached to the second guest virtual router, and it can be accessed only through the web servers and does not have connectivity to the outside world.

The guest virtual network 2 has different subnet or a different VLAN tag and is private to the guest virtual network 1, which means any communication to the guest virtual network 2 has to be routed through the guest virtual network 1. This type of networking architecture is known as a multi-tier network.

In a multi-tier network, there can be multiple CloudStack virtual routers present between different networks of different VLAN tags or different overlay networks, and the communication between these private networks is facilitated by the CloudStack virtual router that acts as the gateway to the communication between the two or more networks, this router can also act as the DHCP server, DNS server, NAT, and for site-to-site VPN access.

Security groups

Security groups can be attached to any particular instance in the CloudStack environment. The security groups act as the firewall to allow or deny the egress and ingress of network traffic. The rules defined in security groups decide whether communication of some protocol, to some port of the instance from a particular source can be allowed or denied. The security groups can also be used to define rule for the outgoing traffic.

The security groups offer an extra level of security or firewall that can be applied to the instances for restricting the incoming and outgoing traffic. For example, the web servers on one VLAN can have security group to allow traffic from anywhere on the Internet to its particular port serving the users' requests, whereas a backend database server can have security group configured to allow traffic only from the security group of the web servers to its database port and deny any other traffic from anywhere. Thus, the security of the database server is maintained by restricting the access only from the web server. Security groups provide firewall configuration at the instance level. There can be one security group with a particular setting attached to multiple instances. Security groups allow a scalable network configuration in cloud over VLANs, where the numbers of VLANs that can be created on a Vswitch are restricted.

CloudStack is built using the above defined components and these components are used for different functionalities in cloud. The users can configure these components differently to configure the cloud as they want. CloudStack can be used to deploy a public cloud where people can access it over the Internet on the go, from anywhere; or it can be used to configure a private cloud that is private to an organization and can also be extended to be used as a hybrid cloud where it offers limited public access.

Before we move on to the installation steps, first let us consider the basic requirements that are needed for the CloudStack deployment. The recommended hardware configuration of the machine hosting the Management Server is as follows, starting with the operating system:

The operating system for the installation of CloudStack 4.0 is recommended to be RHEL 6.3 + 64 bit that is available for download at https://access.redhat.com/downloads or one can use CentOS 6.3+ 64 bit that can be downloaded from https://isodirect.centos.org/centos/6/isos/x86_64/.

Ubuntu 12.04 LTS can also be used for this purpose.

There are builds available for Centos/RHEL and Ubuntu online which make the installation simple.

The CloudStack system can be deployed on physical or virtual machines.

The basic hardware configuration for installation is:

A list of supported operating systems is given in the Requirements section. We must prepare the OS before we proceed to installation of CloudStack Management server. The steps required at operating system level before we proceed with the installation of CloudStack are discussed as follows:

After preparing the operating system, we can now begin with the installation of the management server and MySQL in single node installation. The installation process mentioned here assumes the compilation of the CloudStack package is done on a Linux system that uses RPMs or DEBs. Now, we will proceed with the installation of Apache CloudStack by building it from the source.

# sudo apt-get install dpkg-dev

# sudo mkdir -p /var/www/cloudstack/repo/binary
# sudo cp *.deb /var/www/cloudstack/repo/binary
# sudo cd /var/www/cloudstack/repo/binary
# sudo dpkg-scanpackages . /dev/null | tee Packages | gzip -9 > Packages.gz

# mvn -P deps

#./waf rpm

# cd artifacts/rpmbuild/RPMS/x86_64
# createrepo ./

[apache-cloudstack]
name=Apache CloudStack
baseurl=http://webserver.tld/path/to/repo
enabled=1
gpgcheck=0

Now that we are done with building of the packages, we can continue with the installation of management server.

Installing the management server on a Centos/RHEL instance can be done using yum and this can be done using the apt-get in Ubuntu.

For Centos/RHEL:

# yum install cloud-client

For Ubuntu:

# sudo apt-get install cloud-client

Assuming that we have built the packages from the source as described above, and we have also set up a repository so that the built packages can be accessed over HTTP. We have to add the repository entry in each of the machines so that the provider yum in Centos/RHEL or apt-get in case of Ubuntu knows the path of the repository from where to fetch the Apache CloudStack packages along with the dependencies.

For installing management server on multiple nodes, we need to carry out the steps for installation as described above in the case of single installation on all of the machines.

Next we can continue with the installation of CloudDB that will act as the database server.

The installation steps of MySQL database are also similar to the installation that we did for single node installation. But here we need to configure the database so that it can be connected to multiple management servers. Let's see how to achieve this.

The users can install MySQL from a separate package depending upon the server's OS; or, if you already have a version of MySQL installed, you must check whether there is an upgrade required or not. The MySQL version that has been tested with CloudStack and found to be stable is 5.1.58.

In case you have already got MySQL installed on your system, you must consider upgrading it to the required version (5.1.58) or you can also simply uninstall it and re-install the latest version.

The following steps show the installation of a MySQL server from the yum repository. These steps are for the Master database server in case you are going to create replicas.

Now, we are done setting up the database server and we can return to our first management server.

We are done configuring the CloudStack database in the management server. If there are multiple management servers, you may need to follow the configuration steps as above once again.

You must set the iptables rules for enabling the communication between the management server and database node as well and also add the services to the system services so that they are started by default whenever the system changes its state (started or stopped) using chkconfig and then you can start the management server. This all can be done using the following script:

# cloud-setup-management

Now, we can proceed on to the setting up of the NFS share for the primary and secondary storage as we did after completing the single node installation.

For a production environment, it is highly recommended to use multiple management servers so that there is load balancing for all the requests. For this kind of setup, you must also set up a load balancer configured to send requests based on some algorithm. To balance the load across the management servers you can use various options available in load balancers such as Round Robin with sticky sessions.

#cloud-setup-databases

The management server console is used by the administrator to configure the cloud and to create various types of offerings as per the design and deployment plan. It is used by the users to request resources from the cloud by selecting from the offerings designed by the administrators. Some of the panel options that are available in the UI are discussed in the following sections.

Dashboard tab

The dashboard is the page where you get a brief overview of the health of various services registered in CloudStack as well notifications for various events triggered by the CloudStack system. In the default view, one can see the alerts that are triggered, where as in a project specific view, the dashboard shows the virtual machines, volumes, users, events, network settings, and so on that are specific to a project. The project dashboard screen looks as follows:

From the dashboard, the user can perform a number of functions by navigating to the page directly.

There are total of 3 tabs available which guide to other operations, they are:

• Dashboard: The dashboard screen highlights the number of VMs, storage volumes, bandwidth, and users that are configured with CloudStack.

• The administrator can also manage network resources by using the link given on the right-hand side. On clicking the Manage Resources link on the right side menu, the admin can add new guest network to the CloudStack project, can acquire new IP addresses, and can set up load balancing and port forwarding rules. The administrator can also use the Network tab on the left to manage the network.

• Accounts: The administrator can view and manage members of the project selected. The administrator can also add new members to the project, remove the existing members as well as change the role of a user. There are two roles available by default: user and admin. There can only be one admin user at a time in a project and a user can belong to only one project and one account.

• Resources: On the resources tab, the user can view the limits to various resources on the project. The project administrator can also lower the resources also.

• Invitation: This tab can also appear if invitations are enabled in the global configuration settings (discussed later). Using the Invitations tab, the users can view and manage the invitations which have been sent to new members of the project selected.

CloudStack can be configured in such a way that the users are directly added to it or it can be a necessity for a user to accept the invitation to join cloud. The members to whom the invitations are sent can either accept their invitations or reject them. The pending invitations will be listed here until the timeout specified. The user can also cancel the invitations. Once the invitation is accepted, the user is added to that project.

The invitations can be enabled in CloudStack by setting the parameter project.invite.required to true in the global settings page. There are various other parameters that are used to customize the request.

Events tab

The Events page shows the various events in the CloudStack deployment. It basically acts as the logging place where one can see the log of activities performed in CloudStack. The following screenshot displays a typical event page displaying all the events.

Projects

The Projects tab displays the projects details. The administrator can view all the projects that exist in the CloudStack environment and a user can view the project details of their projects. The creation of projects allows administrators to create groups for dividing their workforce; these groups share resources in the CloudStack environment. An organization can create various projects with different groups of people to share the resources in the CloudStack environment. The project administrators have the privileges to set limits on the amount of resources such as VM instances, snapshots, templates, and volumes. The resources created by a user in a project belong to that project and cannot be used outside that project. The user can also create resources outside a project, but this resource belongs to the user's account and is not a part of any project. A single user may belong to multiple projects and will have access to resources based on the projects assigned to them.

The administrators can also create a project specific network to isolate the project related traffic in the CloudStack environment and can also provide project specific network services such as port forwarding and NAT. CloudStack also provides shared resources which can be shared across projects as well as used by individual users. The options for making resources dedicated to a project or keeping them shared are a part of adding resources.

Administrators

There can be various types of administrators:

• Cloud administrator: There can be cloud administrators who have complete access to the system who can manage templates, service offerings, projects, users, accounts, domains, create, and delete other administrators.

• Project administrator: The project administrators have access to the resources in the project only, they can add, view, delete, and modify the existing users, accounts, which belong to the project. They don't have the privileges to access the physical resources or any other projects.

• Domain administrator: The domain administrators have access to the resources in that domain only and cannot perform actions on resources other than their domain.

You can also integrate an existing external LDAP with CloudStack like Microsoft Active Directory services or ApacheDS. The integration of CloudStack can be done with LDAP or ADFS using API provided by CloudStack. CloudStack searches external LDAP directory tree structure for matching common values for users such as their e-mail address and name. We specify the base directory in our LDAP directory tree and CloudStack will start the search from that directory and return the name of Distinguished Name (DN) of the matching user. The user can use this DN along with their password to log in to the CloudStack. The integration of CloudStack with external LDAP services can be done using the CloudStack API.

Now, as we have explained that there can be various administrators in CloudStack, let's have a look into what are these domains, accounts, and projects. We will go through a step-by-step process of creating users, accounts, domains, and projects. When you first install CloudStack, a domain name Root is already created for you. You can create new domains by going to the Domain tab and clicking on Add Domain as shown in the following screenshot:

You will have to enter the details of the domain that you are creating now:

On clicking the OK button, a new domain of name Cloudstack.packt.com will be created. Now you can add new accounts under this domain from the Account tab and clicking on Add New Account.

The new Account creation wizard is opened where you will have to enter the details of the account.

This operation will create an account of the name packtadmin as well as user of name packtadmin. This user that we are creating with the account can be the user in that domain or the Admin of the domain.

New users can also be added, removed, or modified from the Account tab by navigating to the account into which you want to create the new user.

Let's move on to adding offerings in the cloud which we will be providing to the users. The users as well as the admin can go to the Management server console and request any one of the offerings from the list which we will be adding and configuring in the cloud as a cloud administrator. There are various types of offerings that can be created from the cloud console, they are described below.

Compute offerings

These offerings are basically details about the compute offerings such as the choice of CPU speed, number of vCPUs, RAM size, root device tags, storage type and storage tags, network rate, and other compute choices. To add a new compute offering, we need to move to the Service offerings tab and select compute offering from the drop-down menu at the top, as given in the following screenshot:

To add a new compute offering, click on the Add Compute Offering tab, and provide the appropriate entries as shown in the following screenshot:

The various fields in the screen are described below:

• Name: This will be the name of the Compute offering we are going to create.

• Description: Description of the compute offering we are creating.

• Storage type: This field describes the type of storage that will be provided in this offering. It can be local storage or shared storage. Local storage is the storage from the host on which the hypervisor is connected and the shared storage is the storage that is accessible by NFS, network attached storage.

• # of CPU cores: The number of CPU cores that will be available in with this offering.

• CPU (in MHz): This is the speed of the CPU clock which will be offered to the instance in this offering.

• Memory: The amount of memory available with this offering in MB.

• Network rate: The network data transfer rate in this offering in MBPS.

• Offer HA: This is an option provided to the user, whether he wants to monitor the instance and make it as highly available as possible.

• Storage tags: These are the storage tags that should be associated with the primary storage for providing disk storage to the instances.

• CPU cap: This option is to limit the amount of CPU available to the user to the assigned value, even if there is spare capacity available.

• Public: This option is provided for the visibility of the service offering. Public means that this offering will be available to all the domains in the cloud. If you don't want this offering to be public, CloudStack will let you configure the scope of the visibility of the offering. We can define the scope of the visibility of the offering to a subdomain. CloudStack will prompt to select one of the subdomains from the drop-down list.

Disk offerings

Using Disk offering, we can specify the choice of disk size that the users can request from the Primary storage. For creating a new Disk offering, you need to select Disk offerings from the drop-down menu on the Service Offering page and click on the Add Disk Offering button in the upper-right corner of the screen. You will get a screen like this:

You need to enter all the details in the form as per the offering that you want to create. The fields are described as follows:

• Name and Description: The name and description of the Disk offering that you are creating. This will appear in the service request page when the user requests services.

• Custom Disk Size: This option allows the user to specify the volume size that he wants for the disk. If this is not checked the administrator will provide the size of the volume and the user will get that much amount of the volume. If it is not checked, you will have to enter the size in GB for the offering.

• Storage tags: This option provides the tag that is to be associated with the primary storage for this offering. CloudStack uses this tag to match with the tag of the primary storage volume. The disk is offered to the user from the primary storage whose tag matches the tag provided here. If CloudStack finds that there is no primary storage available with a tag name, the provisioning fails.

• Public: This field specifies the permissions defined for the disk offering. This value determines whether the offering will be available to all the domains in the cloud or only one particular domain.

Network offerings

The network offerings are the set of features that will be available to the users as offerings from the virtual router or any other external network devices on the guest network he is on.

There are various network offerings that you can select from the list, they are as follows:

VPN, DHPC, DNS, Firewall, Load Balancer, User Data, Source NAT, Static NAT, Port Forwarding, and Security Groups.

For adding a new Network Offering, you need to select the Network Offering from the drop-down list on the Service offering page and click on Add new Network Offering button on the right top. You will get a page as shown in the following screenshot, where in you will have the option to select for the network offerings.

The options that are provided while configuring the network offering are:

• Name and description: The name and the description of the Network offering that we are creating.

• Network Rate: This is the maximum network data transfer rate that is allowed in the offering.

• Guest Type: The network offering can be Share or Isolated offering. These have different characteristics as described in Chapter 2, Installing Apache CloudStack.

• Supported Services: These are the services that can be provided with this offering such as the Load Balancer, VPN, DHCP, and DNS. The options available with different services will be as per applicability of the configurations. As an example for a load balancer, you can select CloudStack Virtual router or any other load balancer which is configured in cloud.

• Conserve Mode: This defines whether the conserve mode is to be switched on or off, when this mode is enabled, the network offering will be provided only when the first virtual machine is started in the network.

• Tags: This tag defines the physical network to be used with this network offering.

On these pages, after the creation of various offerings, you can also edit the offerings such as disabling them, editing some properties.

Now that we have got our hold on creating different types of offerings, let's move to adding some infrastructure to the cloud. After which we will be able to create service offerings which will be provided to the end users to request.

When we navigate to the Infrastructure page, it displays the overall capacity of Infrastructure that has been added to the cloud. The screenshot of the page is given as follows:

All the information about the number of Zones, pods, Clusters, and Hosts is provided on the screen. You can click on any button of View All to get the details about each component of the infrastructure.

We will start by adding a New Zone to our environment. For this we will have to move to the zone page and click on the Add New Zone button on the top right. The screen provides us with options to configure the zone we are about to add.

There are basically two types of configuration given as follows:

Basic Zone configuration

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 used when the primary DNS server is not available.

• 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 hosts for the sake of maintenance.

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.

Advanced Zone configuration

When you select the option of creating a zone of Advanced type in the first screen of the Zone, you will get a screen like the one shown below.

The basic information of the advance zone is provided for the following parameters:

• Name: Name of the advanced zone that we are creating.

• DNS1/DNS2: This is the address of the primary and secondary DNS server to be used by the guest VMs in the zone. These servers should be accessible by the public network that we add later.

• Internal DNS1/Internal DNS2: These are the DNS servers that are used by the system VMs in the zone.

• Network Domain: This is an optional field and should be specified if you want a special domain name for the guest VM network.

• Guest CIDR: This field is the CIDR IP range that describes the IP addresses to be used by the guest virtual networks in this zone. It is recommended that the guest CIDR IP range should be different for different zones.

• Hypervisor: This is the list of hypervisor for the first cluster in this zone. Once the zone is created, you can add multiple clusters with hosts of different hypervisors. A cluster is a group of homogenous hypervisor hosts, i.e. all the hosts in a cluster must have the same type of hypervisor.

• Public: This field specifies the permissions for the zone, whether this zone is to be assigned to all domains or a particular domain. If this zone belongs to one domain, then users who belong to that domain, will only be able access it.

After configuring the initial details, you have the option to add multiple physical networks and configure which traffic can flow across them. In this case, you will have to define labels to distinguish different kinds of network traffic.

As you can see in the preceding screenshot, there are three traffic types in the first Physical Network and then there can be number of physical networks which allow traffic between the guest VMs. Each of these traffic types must have a label associated with them in order to distinguish between the different types of network traffic.

These labels must match the labels that you have defined on the hypervisor host. Only one physical network can host the storage traffic, internet traffic and Management traffic. This configuration is done only for the first hypervisor host that is added to the zone, for any other host it can be done after the zone has been created.

After you have assigned various traffic types to the different physical networks, you will have to configure the NetScaler device in the zone as per the Screen 15 of the Basic Zone configuration in the previous section.

You will have to follow the steps from screen 15 to screen 17 to add the Pod in the CloudStack environment as defined in the Basic Zone configuration. After adding the Pod to the environment, you will be asked for configuring the VLAN range for the various physical network that you have defined for carrying the guest traffics for each physical network.

The screen for defining the VLAN range for the various physical networks in this zone is given above. After defining various VLAN ranges for different kinds of traffic, you can proceed to the configuration of pods, Clusters and Hosts in the zone same as described for the Basic Zone.

There can be various other configuration parameters depending upon any other network offerings than those defined in this chapter or it can depend upon the type of hypervisors such as if you select VMWare, you will be asked to enter the details of the VMware VCenter server while defining the details of the cluster (A cluster consists of homogenous hosts—the hosts must have the same type of Hypervisor), as depicted in the following screenshot:

For VMware, it is recommended that you have the cluster defined at the VCenter server before adding it to the CloudStack environment.

After the successful creation of the zone, you can view the details of the same on the zone page and also edit some of the options. The page displaying the details about the zone will look somewhat like this:

You can also add more infrastructure resources to the zone or create another zone after this zone is created. For example, lets say you want to add another host to the zone, it can be done by moving to the host page and clicking on Add Host which will provide you with a screen to enter the details about the new host.

The options for adding another host in the zone are:

• Zone: This is the zone to which we are adding our new host to.

• Pod: The pod in the zone selected above in which the host should lie.

• Cluster: The cluster within the pod which the host is a part of.

• Hostname: The IP address or hostname of the host which is to be added.

• Username: The username of the host.

• Password: The password of the host for the username provided above.

• Host Tags: This can be any tag to distinguish the host for ease of maintenance.

Similarly we can add more clusters or pods to the existing zone by navigating to the desired resource page. We have added the infrastructure to the cloud; we can proceed to adding other resources such as templates and storage.

Creating a template

A template can be created by a number of ways. We are going to discuss them below.

Creating a template using a running VM

We can create a template from a running virtual machine in our environment by following these steps:

1. Create a VM instance with the Operating system that you want and make the configuration changes as per your need.

2. Stop the running virtual machine.

3. Now, the volume of this virtual machine is also in the stopped state, convert this volume into a template.

4. Or, create a snapshot of this volume and then create a template from that snapshot.

Importing a VM to CloudStack

The other way to create a template is to import a virtual hard disk from any other environment into the CloudStack environment.

There are some basic requirements while creating a template from any other environment which enable some functionalities such as the console view and guest shutdown. The requirements are as follows:

• If you are planning to import a XenServer virtual machine, install the PV drivers or Xen tools on each of the machine which you are going to import into CloudStack and convert into a template. The PV drivers or the Xen tools help manage the virtual machine and also provide performance data for them.

• If the virtual machine is part of a VMware environment, install the VMware tools.

We will discuss the steps for importing a template of different OS and different environment later in this book.

Creating a template using the Management console

We can as well create templates using the Management console by navigating to the Templates tab of the left menu and clicking on the Create Template button. The screen looks as follows:

The options while creating a new template are:

• Name and Description: This contains the name and description of the template that we are creating. This will be visible to the end users while creating VMs from the template.

• URL: This asks for the URL of the file (which can be a VHD or a compressed file) which is going to be used to create template and then guest virtual machine from. This file is uploaded to the CloudStack environment. HTTP and HTTPs are supported protocols for this.

• Zone: This is a drop-down list of zones in the environment, you can either create template to be used in all the zones or for some specific zone.

• Hypervisor: Select the hypervisor to which the file belongs.

• Format: This is the format of the template file that we are providing URL for. The format of the template depends upon the type of hypervisor we chose for it.

• OS Type: The operating system of the template we are creating. This will help CloudStack to perform a set of operations and will also help in improving the performance of the guest VM created from this template. In case the OS type is not present, you can choose Other.

• Extractable: Specified whether the template is extractable or not. If it is extractable, the full image can be available for download by the end users.

• Password Enabled: Check this if the template supports the password reset feature.

• Public: Specifies whether the template is to be made public or not.

• Featured: It should be checked only if you want to make this template a featured template more prominent for users to select from the list.

By providing the valid values, the template will be created and you can create new guest VMs based on this template.

After adding a template from the console, you can also add the ISO to CloudStack. CloudStack also supports adding ISO images to the guest VMs by uploading them to the CloudStack environment. To add a new ISO, select the ISO from the drop-down menu on the Templates page and click on the Add ISO button. This will open a pop-up box to allow you to fill in the details shown as follows:

The options available while adding an ISO are as follows:

• Name and Description: The name and description of the ISO that we are adding.

• URL: The ISO that we add in CloudStack is uploaded, so they must be available on a URL. HTTP/HTTPs is the supported protocol for this.

• Zone: Choose the zones to which the ISO must be available.

• Bootable: This property specifies whether the ISO is bootable or not. This property specifies whether the guest VMs can boot off this ISO image or not.

• OS Type: The type of the OS that the ISO has. You can choose other if the OS is not listed in the list. This helps CloudStack to perform certain operations as well as improves the performance of the guests.

• Extractable: This property specifies whether or not the ISO can be extracted. This means that the ISO can also be available for extraction.

• Public: Specifies whether to make the ISO public or not.

• Featured: This option must be selected if you want this ISO to be more prominent, so that users select it from the list.

These templates and the ISOs that we add in the CloudStack environment can be used to create instances. The end users, while requesting a new instance, specify the template or the ISO which is to be used to create the instance in the zone.

We are done creating projects, domains, accounts, and users in our CloudStack environment and as we have added infrastructure to our cloud. Now, if the end users request an instance based on some template or ISO, they will specify the zone in which the instance should be created along with the service offerings and networks. These options are listed according to our configuration in the cloud. For example, the compute offerings that you have added will be listed for the user to select from.

The administrator can also perform all the operations that the user is entitled to. The admin or the user can request storage volumes based on the disk offering that we have added to our CloudStack environment, these volumes are provided to the users from the primary storage of the hosts that we add in our infrastructure. These volumes can be attached to the guest anytime.

Preparing the hosts

When we add a host to our infrastructure, CloudStack installs an agent on the hosts, so that it can communicate with and control the environment. We can install an agent on the host using the following command line:

• For Rhel/Centos:

  #sudo yum install cloud-agent
  

• For Ubuntu:

  #sudo apt-get install cloud-agent
  

The installation of the agent on the host is the part of the host preparation tasks that we carry out so that the hosts can be added to our environment and the guest VMs can be provisioned on these hosts.

The hosts added to the Cloudstack environment provide the following functionalities:

• They provide compute—CPU, Memory, storage and networking resources to the guest VMs hosted on them.

• These hosts also provide interconnectivity to the Internet using high bandwidth TCP/IP network.

• These hosts can be residing across multiple data centers but are grouped under a logical entity called cluster. A cluster is a group of homogeneous hosts. The hosts in a cluster must have same hypervisor installed on them.

The physical network corresponds to a NIC on the hypervisor host and can carry one or more types of network traffic; the choice of traffic depends upon the type of network that you choose in the zone—basic or advanced.

Advanced Zone

In case of a Zone with advanced networking type, the administrator can configure multiple physical networks in a zone. These networks can be configured to carry one or more traffic types as per the configuration done by the administrator.

Guest traffic

This is the network traffic generated by the communication between the guest VMs. This traffic flows over the guest network and it can be shared or isolated.

Isolated

In case the guest network is an isolated one, the guest instances will be provisioned in a network isolated from other networks based on VLANs. There can be multiple accounts in each domain and each account can contain multiple networks. The network isolation is provided for different networks. In this type of isolated guest network, the administrator needs to provide different VLAN ranges so that isolation is provided to each network in a CloudStack account.

Shared

In the case of a shared network, the guests are provisioned in a single guest network and the guest VMs can be isolation from each other using Layer-3 isolation techniques such as security groups. In the shared network the users can define the communication ports from a source which is to be allowed—the IP addresses and the ports for communication are defined. These shared networks can be VLAN tagged or not.

These networks created by the administrator can span the zone, multiple pods, and thus be available to multiple accounts or the administrator can configure it to be scoped to only a single account wherein the users of only that account will be able to create guests and attach them to this network.

There can be thousands of different networks provisioned which are defined using different VLAN ID, IP range, and gateway. The guests in the networks are provided IP addresses from the range specified for the network they are being provisioned into.

Note

Note that Security Groups in advanced networks have many dependencies which may be resolved in the upcoming version of CloudStack—4.1.

Management traffic

As defined above in the basic network type zone, this network traffic is generated when the internal resources of CloudStack such as hosts and system VMs communicate with each other or with CloudStack Management server.

The administrator must configure a unique range of reserved IP addresses to be used for the management network that is to be used for management traffic. There cannot be two resources of CloudStack infrastructure with same the IP addresses even if they are in different zones. The private IP address range is provided to the POD by the administrator and the infrastructure components of CloudStack such as the hosts, console proxy, and secondary storage system VMs are allocated private IP addresses from this range.

The Compute nodes where the Management server and the hypervisors run must be in the same subnet as of the Management network IP address to enable direct communication between them. Thus, the guest VMs, hosts and the management server do not have overlapping IP addresses with the system reserved IP range. For example, the administrator can have a 192.168.20.0/24 subnet from which he can assign 192.168.20.2 to 192.168.20.7 as the system reserved IP addresses and then he can assign the rest of the IP addresses in 192.168.20.0/24 network to the management server and the hypervisor hosts.

• The administrator provides an IP address range to the pod. CloudStack recommends using one private IP per host in the POD. In case of KVM the host hypervisor and the management server may not be in the same subnet. So, in this case, if you plan to grow the strength of the POD, you must provide sufficient IP address to accommodate the number of hosts. In this case, where XenServer or KVM is running on the nodes in the POD, link-local IP addresses can be used to accommodate the large number of hosts. These link-local addresses are private IP addresses that can be assigned to machines by the CloudStack for internal communications only within a segment of a network and are defined as 169.65.0.0/16 in /16 subnet, so it provides around 65000 IP addresses which should be sufficient to accommodate any number of hosts or any CloudStack virtual router.

• In case of VMware vSphere, the number of private IP addresses must be enough to accommodate the total number of customers in the cloud. The IP addresses assigned in this case lie within the subnet defined by the administrator which has around 255 IPs per POD in case you specify 24 as the size of the subnet. The IP addresses in this range are used for the hosts, guest virtual router, and other cloud infrastructure resources, so if you plan to add more hosts in the future, you must specify a greater range of IP addresses with CIDR as 20 which provides around 4000 IP addresses or you can create multiple pods with their own subnets of 24 size that provides 255 * 10 = 2550 IP addresses.

Public traffic

This traffic is unique in the zone with the advanced network type. This is the traffic which is between the guest VMs and the Internet. This traffic requires IP addresses that are publicly routable.

The users can request these IP addresses from the CloudStack UI and can also configure NAT server to allow communication between the guest VMs and the Internet.

The public communication between the guests and the Internet is made possible using the public IP addresses. CloudStack provisions public IP address up to the maximum limit in the account. The account admin/users can use these public IP addresses to set up a NAT instance so that other instances in that account can also have access Internet access. The other instances when try to access the Internet will be routed to the NAT instance, which in turn provides Internet access to them. These IP addresses can also be used to provide load balancing and VPN services.

CloudStack also allows us to access Internet using a single IP address to provide NAT interface for all the accounts within it. This can be done using the Juniper SRX firewall which significantly reduces the consumption of public IP addresses (this is mostly used in private cloud scenarios) enabling the use of single public IP address to provide Internet accessibility to multiple machines.

The administrator can define one or more ranges of public IP addresses to be used by CloudStack, which can be requested by users.

Storage traffic

As described above, this traffic is the traffic generated by the communication between the hosts and the Primary storage, and hosts and the secondary storage. The administrator is asked to configure the storage network while defining the Zone.

Administrator can configure multiple physical networks in the zone and these physical networks can carry any single or group of network traffic. When a user creates a zone with advanced networking, he has the option to create multiple networks and add multiple types of traffic to them, as shown in the following screenshot:

In the screen as you can see, we have added multiple physical networks such as Physical Network 1, Physical Network 2, and Physical Network 3. In Physical Network 1, we have all kinds of traffic. Whereas the Physical Networks 2 and 3 only have Guest Traffic configured.

Now that we have specified multiple physical networks in the zone, we need to configure labels for the different traffic in different Physical Networks. This can be done by clicking on the Edit button below. These labels are used to distinguish and map different traffic with the underlying physical network label.

These networks are used for different kinds of traffic, as depicted in the following diagram:

CloudStack also supports virtual networks, which is basically a logical construct and helps in providing multi-tenancy on a physical network. Lets' say you need a private guest network for your guests, isolated from the other guests on the physical network, then you need to create a virtual network. This virtual network in CloudStack can either be shared or isolated.

When the administrator creates the virtual network, the information is only stored in CloudStack. CloudStack actually activates the resources and creates the virtual network once the first guest virtual machine starts in the network, and when there is no virtual machine in the network, all the network resources are garbage collected, thus it helps in conserving the network resources. The types of virtual networks in CloudStack are:

Network offerings defined by the CloudStack administrator are a set of network services that are provided to the users. The network offerings include network services such as virtual router, DHCP, DNS, and Load Balancer. Network offerings can also be used when you want to extend your networking services. While creating a network offering, administrators have a number of service options that they can add. The list of services supported by CloudStack 4.0.1 is as follows:

Administrators can choose from this list of services to offer while creating network offerings.

There are some network offerings already present with the installation of the CloudStack. The administrators can choose from the default network offerings or they can create different network offerings which can be custom apart from the standard default network offerings available by CloudStack. This creation of different types of network offerings enables the cloud provider to offer different classes of services to the users in a single multi-tenant physical network. It allows different tenants on the same physical network to have different kinds of services such as firewall and NAT.

The administrator selects the network services to be added into the network offering being created from the list given above and they are tagged to map them to the underlying physical network.

While creating a guest instance, users can chose which offering they want to use from the list of offerings, this choice of offerings determines which networking services the guest can use. By default there are three network offerings that are available in CloudStack and there are other network offerings also available which are used by the CloudStack system and are not visible to the end users.

There are various states of network offering such as enabled, disabled, or inactive. The network offering when disabled cannot be used to create any network.

You might have noticed that we have used the term virtual router a lot of times, let us discuss a little bit more about what a CloudStack virtual router is.

CloudStack creates a virtual router when a new network is created; the virtual router provides the network services to the network. CloudStack uses default settings which are defined in the system service offering that is unique for all the virtual routers in the same network. The administrators also have the ability to upgrade the virtual router by applying custom system service offerings. The steps are given as follows:

As already mentioned you can configure multiple network services in a network offering as specified in the list above. CloudStack provides the network services using the virtual router. For example, when you are adding DHCP, DNS, Port Forwarding, User Data, VPN, Firewall, Load Balancer, Source Nat, and Static NAT, you will be asked which system service offering you want to use with them. The system service offering listed here are those which are configured as CloudStack virtual router. While you are adding services such as firewall, load balancer, source NAT, static NAT, port forwarding. CloudStack provides the option to use Hardware Juniper SRX or use CloudStack virtual router.

CloudStack virtual router is the main component of CloudStack which provides most of the network features as discussed above. We will see how it can be used to provision guest instances in a multi-tier network. CloudStack virtual router is automatically provisioned by CloudStack on the hosts for each of the networks that is created using some network offering that has a System service offering using CloudStack virtual router. The virtual router deployed by CloudStack has multiple Network interface cards associated with it which has different IP addresses to serve different purposes. An example is shown in the following diagram:

As explained in the preceding diagram, there are different types of traffic that flow in the cloud and each network is given a separate range of IP addresses. The guest traffic is given a range of IP addresses (10.0.0.0/8), from which the IP addresses 10.1.1.2-5 is given to the guest VMs in the network with the gateway address as 10.1.1.1. These guests can reach Internet using the NAT services provided the virtual router as shown in the preceding diagram. This is how multiple guest VMs can reach internet with one public IP address. The public traffic is shown distinctively in the figure. The link-local IP address is used by the virtual machines to communicate with the hosts.

CloudStack virtual router has 3 NICs with 1 IP address each. These IP addresses are used for different purposes.

If you chose to create a new network with a network offering with network service like DHCP, then CloudStack will create a virtual machine for the use of CloudStack virtual router which serves as the DHCP server for the network and provides IP addresses to all the machines which are created in this network. You can also configure your guest virtual machine not to use this service—it can have an IP address manually configured as well, though CloudStack reserves an IP address from the pool for each guest VM.

Networking is built using various types of network services. In CloudStack administrators can use one or many types of services to be included in the type of networking they want to establish in the cloud. These network services provide different services such as public communication, firewall protection, load balancing, and so on.

CloudStack provides isolation of traffic to VMs by the use of security groups. The security group is basically a group of VMs that provides filtering of the incoming and outgoing traffic as per the rule configuration. We can set the ingress and the egress rules for the network using security groups. The network traffic is filtered according to the rules configured in the security groups. As we have already discussed, a zone with basic network configuration has isolation implemented using security groups. These security groups are very useful in a zone with basic network configuration as all the guest VMs are present in a single network.

The security groups provide IP address filtering and have rules defined within it which define the incoming and outgoing traffic characteristics, like for example, the protocol, port and the source of the communication which is to be allowed or denied. CloudStack provides a default security group which has some rules predefined with itself and it can be modified whenever required. This default security group has rules defined to deny all incoming traffic and allow all outbound traffic. Users can modify this security group or define new ones as per their requirements. An instance is associated with a security group when it is created and it cannot be changed afterwards, this security group can be the default one or any other security group created by the users. The security group associated with the instance defines the traffic that will be allowed or denied for that instance and it can be modified at any point of time and the new configuration will define the traffic rules from that point irrespective of the VM's state (stopped/started).

The zone has a security group feature that must be enabled before the security group functionality can be used in the zone. The enablement of a security group in a zone is defined by the administrator when creating the zone. As we have seen, while creating a zone, the administrator selects the type of network offering, the security group feature is defined in the network offerings and if the administrator wants the security group to be enabled in the zone, he must choose a network offering with security group functionality. The security group feature is provided by the CloudStack virtual router. The network offerings can be created to include services such as the security groups as described earlier. We can do this by selecting the Security Groups check box in the list below while creating a new network offering.

To add a new security group, follow these steps:

The newly created security group appears in the list of security groups.

Once you have added a security group, you can add or delete new rules to it. If a security group has no rules defined in it, no traffic is allowed to it. Add the Ingress and Egress rules as follows:

Follow the same steps for adding an Egress rule to the security group.

Whenever a new guest network is first created, it exists as a database entry prior to its first initialization. After the first initialization, the port group entry is instantiated onto the hosts. This component comes into play when the guest network is defined. The NetworkGuru considers all the parameters like CIDR, gateway or VLAN that are provided by the users for the new guest network. When the first instance is created in this network, the guest network is actually created with the help of NetworkGuru. The NetworkGuru calls the implement() method which acquires the resources from the physical network and allocates them to the guest network which were configured during the creation.

Every time a virtual machine starts in a guest network, it calls the reserve() method to let the NetworkGuru know the resources it needs to start and in the expunge phase, the release() method is called to inform the NetworkGuru for the resources that are being released by the virtual machine and when all the virtual machines in a guest network are stopped, the garbage collector is ran to inform the NetworkGuru using the shutdown() method to release all the resources that have been allocated to this guest network—the network is set to virtual state without any physical resources being allocated to it. The trash() method is used to inform the NetworkGuru when the guest network is deleted. The NetworkGuru is basically responsible for designing the virtual networks and the management of IP addresses.

All these Gurus that are declared in components.xml and are loaded when the CloudStack starts, except the exclusive ones. The Gurus themselves take care that they do not clash with other NetworkGurus. So it is the duty of the CloudStack administrator to configure components.xml to avoid any type of collisions while defining the extra plugins or modules. Like the NetworkGuru for providing VLAN based guest networking cannot work parallel with the NetworkGuru managing the L2-in-L3 networks.

The network elements represent the basic components that make up the CloudStack network. These components are the most basic components that provide all kinds of networking services and also provide the infrastructure for building the virtual networks. The network elements include CloudStack virtual routers, external load balancers that can be any third-party device such as NetScaler or SRX or external DHCP servers or any Open vSwitch. The network element is implemented as an interface which has the methods for different operations. For example, the implement() method configures a specified network on a network element. An instance of the network element is verified to be ready by the ready() method. The prepare() method is used for preparing the network element to add a new network interface to the network which provides basic connectivity. The service provider which is associated with the current instance of network element is provided by the getProvider() method.

All resources that are managed by the network elements are managed by network managers. They are loaded at the CloudStack's startup using the cloud configuration manager.

CloudStack defines many resource classes which abstract the physical or virtual resources that are being managed by the CloudStack. These resource classes can be hypervisors, load balancers, or storage devices.

The main components of CloudStack networks have been described above; let's see how these network flows occur when we create a new network and when we create a new guest instance in that network. There are several processes that are invoked at various steps during the flow. A brief overview of the steps followed is as follows:

These primary storages can be iSCSI or NFS servers or a DAS which are added to CloudStack. For storage servers to be added as primary storages to CloudStack, the server must meet some basic requirements, listed as follows:

As already discussed, the primary storage provides disk volumes to the guest VMs which includes their root volumes. When the virtual machine is created, the root volumes are automatically created from the primary storage and they are deleted when the virtual machine is expunged after termination. The extra volumes as requested by users are also provided by the primary storage. One can easily demand more volume and perform operations such as attach/detach on them dynamically. These additional volumes which are added to the guest dynamically are not deleted when the virtual machine is destroyed.

CloudStack provisions storage to the users as required, but the administrator must continuously check the status of the primary storage and must add more when it is low.

The provisioning of storage by CloudStack depends on the type of underlying hypervisor and the storage server. Due to this CloudStack can support thin and thick provisioning. In the case of thin provisioning, the size of the allocated volume is less than the requested size and it can be expanded up to the requested size as and when the demand increases, whereas, in the case of thick provisioning, the volume of the requested size is allocated at the request time.

The following are the cases when we would use the different types of hypervisors in CloudStack:

In all the other cases, the CloudStack is responsible for mounting and un-mounting the iSCSI target on the host when it discovers that there has been a connection/disconnection.

In the case of thin provisioning, there may come a time when the actual total requirement of storage of these machines exceeds the total storage available. This is termed as over provisioning. We can control the amount of over provisioning in CloudStack in case of NFS.

When NFS share is used for primary storage, CloudStack manages the over provisioning independent of the hypervisor. If you want to use this feature the parameter storage.overprovisioning.factor in the global setting must be set, this parameter controls the degree of over provisioning that is allowed.

CloudStack supports multiple storages to be added as primary storage and enables creating multiple storage pools. The administrators can add multiple NFS shares as primary storage or can add some NFS shares with iSCSI LUNs and add more when the first has reached its capacity.

CloudStack allows adding the first primary storage when creating a zone and you can add more after the zone has been created. To add more primary storage, use the following steps:

When the primary storage has been added to the CloudStack, the description page appears on clicking the primary storage name, there are some actions that you can perform on them. One can place the primary storage in maintenance mode. Placing a primary storage in maintenance mode is recommended if you need to perform maintenance on that storage, for example replacing hardware in it.

When a primary storage is placed in maintenance mode, it first stops all the guest VMs which are provisioned on that device and then it stops the guests which have any extra volume provisioned from this primary storage. In case, the host and VMs are marked as Highly Available, so the VMs residing on the host will be migrated to another host which is not marked in maintenance mode ensuring that they remain available. The other host where the VM is migrated must be in the same cluster in case of VMware hypervisor, or the same pool in case of XenServer.

After completion of maintenance the administrator can bring the storage back online by cancelling the maintenance mode. CloudStack brings back all the guests that were switched off at the time the primary storage went into maintenance mode.

When a new zone of any type is created, CloudStack allows adding the first secondary storage and more secondary storage can be added after the zone has been added. CloudStack takes some time to initialize the device depending upon the network speed.

Once the system is initialized, the secondary storage is ready to use. To add a secondary storage in CloudStack, follow these steps:

When a secondary storage is added to a zone, CloudStack creates a secondary storage VM based on the system VM template to manage this secondary storage. This secondary storage VM is created on a host and the VM carries out variety of tasks in the background such as downloading a new template to a zone, copying templates between zones, and performing snapshot backups. In fact, all the submissions to the secondary storage go through the secondary storage VM. CloudStack uses a separate network interface for all these types of traffic such as templates and snapshots. It is recommended to use a high bandwidth network for the storage traffic, this allows fast downloading and snapshot copying.

After the secondary storage has been added to the CloudStack, the administrator can also change the secondary storage or its IP address without any loss of data, but the proper procedure must be followed for this. After changing the IP address of the secondary storage, the administrator must also change it in the database to ensure the proper functioning of CloudStack.

To change the database entry of the secondary storage, log in to the database server and execute the following commands:

mysql –u root –p password
mysql> Use cloud;
mysql> SELECT ID FROM HOST WHERE TYPE='SecondaryStorage';
mysql> UPDATE HOST_DETAILS SET VALUE='<NEW_VALUE>' WHERE HOST_ID=HOSTID AND NAME='orig.url';
mysql> UPDATE HOST SET NAME = '<NEW_VALUE>' where type = 'SecondaryStorage';
mysql> UPDATE HOST SET URL='<NEW_IP_ADDRESS>'WHERE TYPE = 'SecondaryStorage';
mysql> UPDATE HOST SET GUID='NEW_VALUE' WHERE TYPE ='' 'SecondaryStorage';

This is done to update the new IP address of the secondary storage in the CloudStack database. The database "cloud" is the database that is used by CloudStack for storing the value of the resources. The steps are also depicted in the following screenshot:

After making these changes, the administrator must log in to the UI and stop and then start (not reboot) the secondary storage VM. The administrator can also change the secondary storage when he wants to by using the following steps:

CloudStack also allows OpenStack object storage (Swift) to be added as a secondary storage. In cases where Swift is being used for secondary storage, it is enabled for the entire CloudStack, and then after Swift is configured, NFS secondary storage is set up for each zone. All traffic; such as templates and other secondary storage data passes through this NFS storage before being forwarded to Swift. In a way the NFS server acts as a staging area for all secondary storage traffic.

This Swift storage is an object storage which spans across the cloud providing data to all zones. Each of the objects is stored in the Swift container which can be pulled by any secondary storage from anywhere in the cloud.

When an NFS share is used as the secondary storage, you might need to copy templates and snapshots from one zone to another. Using Swift avoids this situation because all the templates and snapshots are stored in Swift, which is accessible from all over the cloud.

Before adding any zone with NFS share as secondary storage, Swift must be configured in the cloud. To do this, perform the following steps:

Swift is deployed as a part of the storage foundation in CloudStack and apart from secondary storage it is the underlying core engine of the storage infrastructure in CloudStack. CloudStack allows Swift to span multiple zones which can be in different geographical locations or in a different network. Swift allows an object of a maximum 5 GB in size to be uploaded and downloaded. It can also support unlimited sizes of the object using segmentation where the object is split into segments using the Swift tool so that parallel uploads can be done.

In order to add more volumes to a guest, the user must create volume based on the disk offerings defined by the administrator. New volumes can be requested and attached to any guest by both administrators and users.

When a new volume is created in CloudStack, it is added as an entity only and no physical storage is allocated to it until it is attached to any guest. This helps in optimizing the storage usage. In order to create a new volume, use the following steps:

After you have entered these values, a new volume appears in the volume screen with the state set to Allocated. This volume is just an entity in CloudStack and no physical storage is allocated to it, physical storage will be allocated when you attach this volume to a guest.

A volume is created based on the disk offering selected by the user which defines the size of the volume, but it doesn't allow changing the size of the volume once it is created. However, it is possible to change the size of the disk using tool known as VHD Resizer, this tool allows you to import the VHD and resize the volume. The VHD Resizer can be downloaded from http://vmtoolkit.com/files/folders/converters/entry87.aspx. After you have changed the size of the VHD using the tool, follow these steps:

After a new volume is created, this volume can be attached to suitable guests, the users can also move storage volume from one guest to another by detaching the volume from the first and attaching it to another. A volume can be attached to a guest VM to provide extra storage to it. Any volumes which are not attached to any guests are free to attach to the guest VMs, it can be the newly created volume or when a volume is migrated from one storage pool to another. To attach a volume to a guest, follow these steps:

CloudStack provides a feature to detach a volume from one guest instance and attach it to another instance in the same cluster. A volume cannot be attached to any instance until and unless the instance is of the same hypervisor type as the volume, because different hypervisors support different disk formats. If you are attaching a volume to an instance in a different cluster, it may take several minutes. In order to detach a volume from an instance, follow these steps:

The volume becomes available now and can be attached to any other instance of the same hypervisor type. Both the administrator and the users can perform this operation.

When a guest is destroyed, the root volumes are automatically deleted with it but the data disk volumes mounted on it are not deleted. When a volume is deleted, the storage space is allocated back to the primary storage. CloudStack has a garbage collection process which permanently destroys the volumes (expunged) when they are deleted. The users can control the expunge time of the volume by setting some configuration parameters in the global settings page. These parameters are as follows:

After deletion the volume can still be recovered, but after the volume is expunged it is destroyed permanently and the entry in the database including the meta data is removed.

To delete the volume use the following steps:

In order to create a snapshot, the instance to which the volume is attached should be in the stopped state to avoid inconsistency of data and in the case of KVM hypervisors, the snapshot cannot be created if the VM is in the running state. Follow these steps to create a snapshot from a volume:

The snapshot will be created and you can view it in the Snapshot tab of the Instance tab for the instances as shown in the following screenshot:

The snapshot can also be created for volumes using the same set of steps from the Volumes tab. These snapshots can be used to create another instance, template, or volume. The snapshot can be created from the Instances tab as well as from the Storage tab by selecting the volume for which you want to take the snapshot.

CloudStack also provides the ability to program the automatic creation of a snapshot, that is, the users can program the creation of a snapshot which creates recurring snapshots of volumes as per the configuration. In order to create recurring snapshots of a volume, use the following steps:

In case of recurring snapshots, the users can specify the number of snapshots that should be kept, which is known as a retention period, by specifying a value in the Keep snapshot(s) field in the preceding window. The snapshots that are older than the retention period are deleted.

Follow the steps listed below to create a volume from a snapshot:

The new volume will be created from the snapshot and will contain all the data and configuration information that is in the snapshot.

To create a template from a snapshot use the following steps:

The template created from the snapshot can be used to create new instances.

CloudStack allows the creation of temporary passwords and allows you to change the password for admin or root users in guest VMs from the CloudStack UI. The password management feature of the template can be enabled which includes downloading and installing a script on the template. When new instances boot up from such templates, the script in these instances tries to contact the virtual router via HTTP and the virtual router sets the password for the new instance. If the script is unable to contact the virtual router, the instances boot up without setting any password.

CloudStack allows the administrator to control the snapshot feature. They can be used to control the creation and use of snapshot in CloudStack. The configuration parameters are as follows:

CloudStack allows migrating a volume from one storage pool to another, but the pools must be in the same zone. The volumes can be root drives or any other data disk drives. This feature is supported only in XenServer, KVM, and VMware. This feature helps with balancing the load over different storage pools and increases the reliability of virtual machines by moving them into a different storage pool when the original pool is experiencing issues. In order to migrate a volume from one storage pool to another, use the following steps:

CloudStack also allows the migration the root volume of an instance from one storage pool to another. To do this, follow these steps:

This service offering is defined for the compute resources for the guest VMs in the cloud.

In this offering, the administrators define the amount of CPU in terms of cores as well as the processing speed of a CPU in Mega-Hertz, the amount of memory, the network rate, and other resources.

When a user requests a unit from this offering, the resources mapped with the service offering are provided to him. CloudStack tries to match the logical value of MHz with the value provided in the compute offering.

The administrators can create a compute offering from the Service offering page, using the following steps:

The guest VMs can be tagged as Highly Available (HA). This is enabled by selecting the Offer HA option. CloudStack provides a global configuration parameter, ha.tag, to set the hosts which can be used for HA enabled guests only. If the guest is selected to Offer HA, it will be provisioned on the hosts dedicated for HA enabled VMs.

In case of VMware hypervisor, CloudStack uses the native HA feature provided by VMware.

In case of KVM/XenServer, CloudStack uses the storage heartbeat to detect if the HA is to be performed or not for the HA enabled guest VMs. The agent resides on the XenServer/KVM continuously writes the time stamp on the shared storage, and in case the storage ping times out the HA job will be started for the guest VMs that are HA enabled.

The HA service is installed on the host, but the cluster is the basic unit of availability in CloudStack, so all hosts in the cluster must be enabled for cluster uniformity.

The other type of service offering is related to the disk or the storage resource. The disk offering is used by users to request storage from the cloud. The administrator defines different types of disk offerings based on the size and type of storage that the users can request from the cloud.

When a user requests storage using one of the disk offerings, the resources mapped to that offering are allocated for consumption.

The steps for defining a disk offering are discussed as follows:

The system service offerings are used for creating the CloudStack system VMs such as virtual router, console proxies, and other system virtual machines. The system service offering is used to create virtual machines that are used by CloudStack to manage and provide services to the cloud. These system service offerings are used while creating a new network offering (to be discussed next). When the administrator creates a new network offering that has services such as DHCP, DNS, and security group, these services are provided by the system VMs of type Domain router in the CloudStack which can be created using one of the system service offerings.

While defining the system service offering, we provide the information about System VM Type. CloudStack provides some default system service offerings. System service offering provides a way to create custom system offerings and use them for creating system VMs.

In order to create a new system service offering, follow the given steps:

The preceding screen has the same options and fields as creating a new compute offering. For more details please see Chapter 4, Apache CloudStack Networking.

The other type of service offering is the network offering. The network offering is used to create a network service. Whenever an administrator creates a new network in any zone, a network offering is selected based on which the new network will have the services and scope. The network offering defines the kind of network services which are included with it. A more detailed insight of creating a network offering was discussed in the previous chapter.

The CloudStack system VMs are based on some system service offerings. For example, a security group service in a network is provided using the CloudStack virtual router, whereas a Firewall service in a network can be provided using the CloudStack virtual router or a hardware device. The networks are created using these network offerings.

After the VM instance is created, the user will need to access it and perform operations on it such as deploying applications, and testing them. The user can access his/her instance by using the following steps:

The user can also access the VM instance directly, but before this the user must ensure that the SSH port is open on the Firewall, otherwise the user needs to disable the firewall to access the guest VM instance.

In cases where SSH is not enabled in the instance, the user will not be able to remotely access the VM via SSH. This depends upon the template or ISO from which the instance was created. In order to enable the access via SSH, the user must access the VM from the console and enable SSH before accessing it directly.

In case of a basic network zone, if the user wants to perform operations which require other ports on the instance, he must provide a rule in the security group which should allow the communication on that port from a desired source.

If there is some other external firewall protecting the VM instance, the user will have to add rules to allow the communication for accessing the VM directly.

After the VM instance is created, the user can perform these operations directly from the console by right-clicking on the VM instance. The user can stop the instances which will shut down the operating system by shutting down all the applications. The user can also reboot the instance or destroy the instance.

Once the guest is destroyed, the VM can still be recovered until it is not expunged. After the instance is destroyed, the guest is expunged after the expunge interval. Once the VM is expunged, it cannot be recovered. When the instance is destroyed all the resources that are being used by it are reclaimed and given back to the resource provider. The volumes associated with the VM are deleted and recollected by the primary storage. We can see these icons in the following screenshot:

CloudStack allows live migration of the VM instance, both automatically and manually. CloudStack live migrates a guest VM instance if the High Availability feature is enabled in the service offering from which the guest has been created. CloudStack also live migrates the VMs from the host which is marked for maintenance to another host in the cluster in order to prevent any disruption of service. The manual live migration operation can only be performed by the root administrator of CloudStack who belong to, root domain's admin account.

The root administrator can move a VM instance from one host to another host without any interruption to the services to the users or without going into maintenance mode. The VM instance must be in the running state for this operation and there should be resources on the destination host so that it can accommodate the VM. If the destination host doesn't have enough resources for the VM, the VM will remain in the migration state until it gets all the resources on the destination host. The VM that is to be migrated must not have any local disk associated with it.

The administrator can also set some parameters such as the retry time interval for migration when it fails, and the wait time before the migration finishes. These parameters are given as follows and are shown in the following screenshot:

The administrator can also migrate the instance manually. To do this, use the following steps:

The administrator can also perform various other operations from the console after the VM has been provisioned such as detaching the ISO, editing the service offering that was used to create the VM (the VM must be stopped before doing this), resetting your password, and editing the details of the instance. The CloudStack Web UI also provides the console for viewing the details such as statistics of the VM instance and the extra network interfaces that are attached to the VM.

In case of Citrix XenServer, a XenServer poll master is created using the XenCenter client which contains various hosts. While doing this CloudStack adds all the slave hosts in the XenServer pool master. The system VM control channel and the network management both work at the host level. Refer to the following screenshot:

In case of Oracle VM, CloudStack integrates with the OVS-agent deployed on the hosts and doesn't use the OVM manager. CloudStack itself configures the ocfs2 nodes. There are various types of templates provided by Oracle such as the DB frameworks application built-in which helps the customers to quickly deploy the Oracle services. In this case, CloudStack requires a helper cluster to support the creation of the OVM instance. The domain router is automatically created in the helper cluster when the first OVM instance is created. The OVS agent helps in storing data in the local database on the host. Obviously, only supported OS types are provisioned on the Oracle host. All the Linux/Solaris templates must be obtained from the Oracle site whereas Windows can be installed from an ISO on Oracle VM hosts. Oracle recommends the usage of iSCSI devices for storage while using Oracle VM. It is the user's responsibility to set up the iSCSI device on every host.

While using OVM, there are certain limitation like CloudStack needs a helper cluster such as XenServer or KVM or VMware to support OVM hosts and the system VM cannot be deployed on these hosts because OVM doesn't support Debian guests.

In case of RHEL KVM, CloudStack integrates directly with libvirt and Qemu using the cloud agent and manages the snapshots, system VM control channel, and networks at the host level. CloudStack supports RHEL 6+ and Ubuntu 12.04-based KVMs. In fact, CloudStack depends on the libvrt and Qemu versions, so if you are using any other operating system, make sure the following versions are available:

In case of VMware vSphere, CloudStack integrates using the VCenter. CloudStack supports system VM control channels using the CloudStack private network and deploys a system VM on the hosts to manage the snapshot and the volume. The networking, in case of the VMware cluster, is managed using the vSphere vSwitch. While adding a VMware based zone, it is recommended to create a cluster of hosts on the vCenter and then add the cluster to the CloudStack. The vCenter cluster is mapped directly to a CloudStack cluster under the Pod.

The vCenter cluster integrated with CloudStack can only belong to one vCenter datacenter because the scope of the vCenter datastore used by the vCenter cluster is limited to one vCenter datacenter and the scope of the vCenter vSwitch that is being used by the vCenter cluster is limited to one vCenter datacenter. When a vCenter datacenter resource is shared outside of CloudStack, it may create problems.

When a new VMware cluster is added to the CloudStack, the CloudStack management server bootstraps a system VM and a secondary storage VM to manage the secondary storage which helps in template processing and volume, snapshot or template operations.

CloudStack manages network in VMware using the vCenter vSwitch. The setup of vSwitch and NIC-bonding is done through the vCenter. CloudStack creates networks by creating portgroups dynamically and propagates the network across the cluster which helps in independent VM live migration both in CloudStack and vCenter. The vCenter default vSwitch ports usually need to be extended to support the networks in CloudStack.

CloudStack takes snapshots at the volume level whereas a snapshot in vCenter is taken at the VM level. Use the following steps to take a snapshot:

The summary of CloudStack integration with different types of hypervisors is depicted in the following diagram:

CloudStack by default has a root domain within which all the domains are created. This root domain is a special domain. The administrators can change the name of this using the API call. All the other domains are created under this domain. These domains can contain multiple accounts of user and admin types (discussed later in the chapter).

Domains contain accounts and an account can be of two types—Admin or User.

All users created under an Admin type account, under root domain are cloud administrators and have privileges over the CloudStack environment however the users are tenants and can consume the resources provided under the domain or project.

The domain and zones share a many-to-many relationship. A single domain can host multiple zones or a zone can also belong to a particular domain. In case of configuring a public cloud type architecture, the Root domain can contain a zone which will be accessible by all the sub-domains. It is recommended to have sub domains under the root domain and the zones must be created for these subdomains.

The domains serve as the resource boundary and help in providing security as well. The domains provide a limit on the amount of the resources, as well as the scope of resource usability; for example, who can use those resources. The domains provide a user structure as well as the resources these users can have access to.

As explained above, all domains are created within the root domain. To create a new domain, follow these steps:

A new domain is created under the root account and now you can perform certain operations on it such as editing, deleting the domain, creating a new subdomain, or updating the resource count for that domain.

For deleting a domain, click on the cross button and it will ask whether to force delete the domain or simply delete the domain. A domain has accounts and projects within it, and if you select the Force delete option, the operation will delete all the resources within it like the accounts in that domain, projects, and the users in that domain.

An account can be created within a domain. For creating a new account, the domain administrator or the CloudStack administrator can follow these steps:

Fill in the fields, which are explained as follows:

The network domain can be assigned at the account level, domain level, or the zone, and they override the one defined in the above hierarchy. And if it is not specified in any of them, it is taken from the global configuration.

After entering all the details and clicking on OK, we create a new account as per the details entered. Once the account has been created, there can be various operations that can be performed on that account such as viewing all the users, creating new users, deleting, and so on.

There can be multiple accounts of the two types (admin/user) within a domain. The accounts are useful in organizations that want multiple administrators for different departments and have shared resources among these departments.

The accounts own the resources. Whenever an account is deleted all the resources associated with the account are also removed.

Projects allow the users to share the control of resources between multiple accounts. The resources can be owned by the project and they can be accessed and controlled by multiple accounts within the same domain. This can be useful when different account members want to work on shared resources, then a project can be created to include the members from different accounts. There is only one project administrator in a project who can invite and revoke to add and remove accounts within the same domain as the project. The project administrator doesn't have any permissions on the account level resources. The project administrator can be changed and may belong to any account within the project. A brief understanding of project, as explained above, can be shown in the following diagram:

CloudStack is configurable to allow end users to create projects by setting the global parameter allow.user.create.projects to be true. This will allow end users to create project otherwise only CloudStack administrators or domain administrators will be allowed to add new projects. After changing any global parameter, it is necessary to restart the management server to make the changes take place.

For adding a new project, follow the following steps:

The project owner can add accounts in the same domain as the project. Click on the Add accounts button to add accounts to the project. This can also be done by navigating to Project in the Project page and adding a new account on the Accounts tab, as shown in the following screenshot:

Enter the name of the new account you want to add and then click on Add account.

The Projects page has various operations that the project owner can perform on the project such as updating the resource counts and editing the details.

The Resource tab of the project is used to provide limits to resources in the project such as:

The project owner can edit this information up to the maximum default limit set by the global administrator of the CloudStack.

When the project owner decreases the limits, and there are already more resources than the new limit, then the resources whose count is above the limit are not affected, though new resources can only be added when the resource count goes below the limit given.

The default limits that are provided to the resources when any project is created can be changed by editing some global configuration parameters by navigating to the Global Settings page by clicking on the Global Setting tab on the left panel. This action can be performed only by the CloudStack administrator. These parameters are:

After setting these parameters, the management server must be restarted in order to make the changes take effect.

This feature allows the administrator to send invitations to users to join a project.

Users can be added to project directly or by sending invitation to them. If we want to use the invitation feature, we have to set the global parameter project.invite.required to true. There are other parameters which are also related to the invitations. These are as follows:.

After the configuration of invitation to be used to add members to the project, the project owner can invite members to the project by sending them invitation by following these steps:

This will send the invitation to the user. When the member accepts the invitation before the timeout, he will be added to the project. The project owner can manage invitations by going to the Invitation tabs for the project.

The project owner, the domain administrators (to which the project belongs), and the CloudStack administrator have the permissions to remove any member from the project. When a user is removed from the project, the resources that belong to the user are still in the project which can be used by other members. For removing a member from the project, follow these steps:

CloudStack projects can also be suspended or deleted as per the need. When a project is suspended, the resources owned by it are still present, but they cannot be used by any user, neither can any user create new resources in that project.

When a project is deleted, all the resources in that project are destroyed and all the members are removed from that project. The status of the project changes to disabled, pending deletion and then after all the resources are removed, the project is deleted.

For suspending or deleting a project follow the steps below:

CloudStack provides two different types of views on the user interface for users who are associated with any projects. These users have Default and Project view in the console. They can switch between any of these two views and see the resources associated with each. While switching to the Project view, the users can select which project they want to view. When a user switches to the Project view, by selecting a particular project, they can only view information related to that project ; for example, only the VMs provisioned in that project, and so on.

There can be only one project administrator at a time and the project administrator can pass the role of administration to other user.

The users in the project can still create resources outside the project and these resources can be created under the account to which the user belongs. The resources created in the project by any user are owned by the project and any user in the project has the permissions to work on them. The resources that the user creates in a project are still within the project even if the administrator removes the user from the project.

CloudStack also allows creating project-level network configurations in the cloud so that the project traffic is isolated. These network configurations may include any services such as port-forwarding, load balancing, and VPN.

CloudStack projects can also make use of shared resources available outside the project available within the domain. The project can use any offerings defined in its domain.

CloudStack allows users to deploy the management server (its core component) in high availability mode so that if one of them is down, the other continues to service and there is no interruption in the service. These multiple management servers can be load balanced as well, so that the requests can be distributed among them.

All the management servers use a MySQL database in the backend that can also be deployed in high availability mode by using MySQL Replication.The MySQL cluster has a master among them and other servers replicate the data from the master, so that if the master is down, one of the slave nodes can be promoted to start functioning as the master. The MySQL database provides manual failover in the event of data loss.

We have already seen the Multi node installation of CloudStack in the installation chapter. In a multi-node installation of CloudStack, the database and the management server are deployed on two different systems. The management server can be installed on multiple systems to provide high availability of the management server. These multiple management servers are stateless and are behind a load balancer. Since the management servers are stateless any request to any of them would yield the same result. They are in active-active mode, which means all the management servers are continuously working at any point in time. The load balancer helps in distributing the request load between the multiple management servers. All the management servers interact with the same MySQL database in the backend.

The preceding diagram describes the architecture of a multi-node highly available CloudStack deployment. It is clear that if any of the management servers are down for any reason, the other management servers can continue to function. While deploying CloudStack, one can add more features to it by deploying different management servers on different physical hosts so that the chances of failure become less. However it should be noted that since all management servers connect to the same MySQL server, the database server is the single point of failure. There will be some time lag between the master database server failing and the slave server being promoted to master.

As mentioned earlier, CloudStack uses a virtual router to provide several network services. These virtual routers are created for each network which is created from a network offering that has a virtual router to provide several network services. This virtual router is very much critical to the cloud, because it provides the network services to the guest virtual machines. CloudStack provides a facility to enable a redundant virtual router in the guest network. This redundant virtual router provides the guest network the ability to recover and continue operation if one virtual router is down due to any reason. If the user enables this feature, there will be two virtual routers in every network. One of them is known as the master that functions actively and accepts/responds to the user VM's request, and other is called the backup and it is present in the passive mode. In case the master router is down, the backup router takes its place. The backup router is activated in a few seconds of time and ensures minimum downtime. The backup router after activating becomes the master router and another router is launched as a new backup.

To enable this feature of redundant virtual router in CloudStack, follow these steps:

For recovering the network if the router is down, in a network with redundant router capability enabled, follow these steps:

In case the router appears to be running, but the host is already disconnected, follow these steps:

In this section we shall discuss storage high availability for both primary and secondary storage.

CloudStack provides in-built features which helps in deploying and maintaining a highly available system. CloudStack supports Network Interface Card bonding and the use of separate networks for storage as well as iSCSI multipath which helps in ensuring high availability in various situations. Let's see more about how CloudStack can be leveraged to provide high availability to VM instances.

CloudStack HighAvailabiiltyManager uses the Queue component to run the following actions:

As mentioned, the HighAvailabilityManager updates the state of the process in the database. The state can be checked in the op_ha_work table. CloudStack also has a cleanup process which deletes the cancelled or completed tasks.

The whole process can be depicted in the following flowchart.

HighAvailabilityManager can be configured as well for some of the parameters like the ones given below. To edit these configuration parameters, follow these steps:

CloudStack also supports storage migration between hosts which allows users to migrate VM instances from one host to another in the same cluster or different clusters in the same pod or different pods in the same zone.

For migrating the VM instance, the destination can be flexible which allows the VM instance to migrate to a specific host, or just cluster/pod with some id or storage pool by providing the ID.

CloudStack allows storage migration for all the hypervisors such as XenServer, KVM, and VMware.

A VM instance may be migrated from one host to another in the following scenarios:

The storage migration in CloudStack is carried out using an API MigrateVMCmd that requires parameters to migrate the VM, such as pod-id, cluster-id, host-id and VM-id. Among these parameters, the VM-id is required and the other parameters are optional. The VM migration is dependent on the parameters provided for example, if the cluster-id is present and the host-id is not given, the VM will be migrated to the any of the hosts in the cluster with the required space.

The process is as follows:

The storage migration involves the copying of the data volume of the VM instance from the source to the destination. So, this may consume a lot of bandwidth. CloudStack supports the use of separate networks for storage as well as it supports iSCSI multi path.

The usage of separate paths for the storage ensures that the network's bandwidth doesn't get choked while performing tasks like storage migration.

Counters are related to the performance of the VM instances and are used for monitoring the health of the backend services and the servers. These counters can be SNMP-based counters or can be other counters that are supported by the load balancers.

Conditions are the criteria based on which the action is taken on the auto scaling group. It utilizes the counters defined above. Conditions are defined based on the counters and time frame. For example, a condition defined as x percent of CPU Utilization for y minutes can be used to trigger an auto scaling action. These conditions can be used to trigger an auto scale action.

Every auto scaling group has an auto scaling policy which defines the auto scaling action based on the conditions defined in the group. The auto scaling action can be used to scale up or scale down the number of servers.

Auto scale VM profile defines the profile of the VM that is to be used in the autoscaling group. It may be defined based on the some templates or service offerings, etc. Whenever any machine is provisioned based on the scaling group, the VM instance will be created using the profile defined here.

The auto scale VM group is used to associate the policies with the load balancing rules. We can define the size of the group in the auto scale VM group. The size of the group defines the maximum number of instances that can be present in the group.

The modules described above are defined in CloudStack. It provides various APIs for performing actions whereas the modules described below are a part of the NetScaler system.

The collector or the monitor collects information from the guest VM instances periodically. The timers are defined for the collector to collect data from the instances based on some given metrics. The timer can be configured by users. The monitoring framework in NetScaler supports packet inspection.

The aggregator collects the metric values based on the algorithm defined such as average, maximum, and minimum. The aggregator collects metric data from the collector and computes the sum or average, as configured for a given time duration.

The triggers are alarms which monitor the output of the aggregators, and then evaluate the auto scale conditions based on the all these parameters, and if the conditions are satisfied, generates a trigger or an alarm. The trigger generator runs its job on a scheduled basis.

The trigger/alarm generator passes the trigger/alarm to the trigger/alarm handler over HTTP using a JSON payload. The handler in turn evaluates the alarm and initiates the action of scale up/down in the autoscaling group.

The following diagram defines the autoscale group workflow and the placement on each of the components defined above.

Steps executed while autoscaling:

Autoscaling can be configured in CloudStack using the APIs provided and any other device like NetScaler.

Autoscaling and high availability features play an important part in any cloud environment. These features increase the application's availability and performance by providing a minimum amount of downtime and scaling up and down the number of resources based on the number of requests to optimize the resources used for an application and thus minimizing cost and resource utilization. For example, High Availability ensures there are replicas of applications running in case one of them is down and scaling ensures the optimum number of servers as per the needs of the application at any given point in time.

As described in Chapter 4, Apache CloudStack Networking, CloudStack implements its networking features using many different components which users can take advantage of to create a customized service of their own.

CloudStack provides a module-based implementation of classes interfaces, and dynamic configuration management system using which the users can modify the management of different types of networks in CloudStack.

Using these classes interfaces, the users have the ability to replace the traditional way in which CloudStack manages the guest networks. The basic components of the CloudStack networking module are mentioned as follows, the detailed functioning of each is given in Chapter 4, Apache CloudStack Networking.

CloudStack allows us to add new network components which can be managed using the resources. The components can be managers, elements, resources, or network gurus which can be added to the component.xml file. Whenever a new component is added to CloudStack, it is instantiated using the component locator. The users can define the components using the following steps:

Just like defining the network gurus and network element(s), we can define new components for network managers and resources, as per our requirements.

The users can either edit the components.xml file or extend the component library by specifying the library in components.xml as follows:

<management-server class="com.cloud.server.ManagementServerExtImpl" library="com.cloud.configuration.AnotherComponentLibrary">

After the components are defined in components.xml or in the extended library, they can be referenced using the @Inject annotation. This annotation loads the instance for the component loaded from the component locator.

The users might need to add a global configuration parameter for enabling the network managers. It must be ensured while coding that the code must also check the value for the parameters in order to ensure that gurus/elements/managers are not triggered for the wrong kind of network.

Users can declare the new network component and create new components so that they can create custom virtual guest network services and manage them via CloudStack. Using their knowledge of the different network components, users can plug new network solutions into CloudStack and provide it as a service by creating network offerings using the new network elements.

In order to integrate NetScaler with CloudStack, there are some functional requirements which should be met; they are as follows:

The NetScaler load balancer can be added to a zone to serve as an external load balancer. The administrator must provide the login credentials to the NetScaler otherwise the addition will fail.

Along with the credentials, the public and private interface of the NetScaler external load balancer should be provided.

The load balancer feature in the NetScaler load balancer must be enabled in case CloudStack fails to enable it.

When a new guest network is created using a network offering with NetScaler load balancer feature enabled, it is created using the following series of steps:

Before moving onto the integration of Nicira NVP to CloudStack, let us review some of the prerequisites to do so:

To continue with the integration of CloudStack, we should have the following information:

Every guest network created has its broadcast type set to a logical switch which is created for this network on the NVP controller.

If the state of the network is Implemented, the broadcast URI has the UUID of the logical switch.

The NICs connected to the logical switches will have their logical switch UUID listed in the database table nicira_nvp_nic_map.

In order to use the Nicira NVP plugin in CloudStack, the network service provider has to be enabled on the physical network which can be done using the following API calls:

addNetworkServiceProvider
name = "NiciraNVP"
physicalnetworkid = <the uuid of the physical network>

updateNetworkServiceProvider
id = <the provider uuid returned by the previous call>
state = "Enabled"

When we configure a new zone, we need to create a new physical network for the guest traffic and select STT for the isolation type as given in the following screen:

We also need to set the Xen guest traffic label to the same as the label of the integration bridge.

To add a new Nicira NVP device, we can use the following API commands:

addNiciraNvpDevice
physicalnetworkid=<see step 1>, 
hostname=<hostname or IP of the controller>
username=<admin username>
password=<admin password>
transportzoneuuid=<transport zone uuid>

When we create a new guest network, we must create it in the physical network with its isolation type set to STT. The NiciraNvpNetworkGuru will configure a logical switch on the NVP controller when the first virtual machine is launched in the guest network.

When this virtual machine is starting up in the guest network, the NiciraNvpElement will create logical ports for the NICs of the virtual machine in the guest networks and then attach these NICs to the existing logical switch.

As per CloudStack Version 4.0.x, all the Nicira NVP setup is considered as a device which can be added and removed from a physical network. This device is added to the physical network using the API call addNiciraNVPDevice which enables the plugin on the physical network and any guest networks created on that network will be provisioned using the Nicira NVP controller.

To delete this device, we can use:

deleteNiciraNVPDevice
nvpdeviceid: the UUID of the device.

And to list such devices we can use:

listNiciraNVPDevices

Though the default user interface that CloudStack provides is easy to use, the users might want to change the user interface. CloudStack provides various APIs to do so.

CloudStack UI is built using the technologies such as HTML/JSP, CSS, and JavaScript, and it uses jQuery 1.4 as the JavaScript library for all the AJAX calls, event handling, and animations. The current UI shows the resources dashboard, infrastructure configuration page, and many other features, but users may use the APIs to modify and implement some more functions via UI.

All the UI-related files are present on the management server at /usr/share/cloud/management/webapps/client/. You may find various files in this directory which implement the UI for CloudStack. The users can change the dashboard style by editing the CSS file which implements the dashboard style configuration.

The users can also change various parameters, as we will see in the following sections.