The management too has been developed for the operational teams. It simplifies and secures data-center management. It facilitates management by suggesting a simple and concise language dedicated to easy and synthetic administration. This language allows large network with of hundreds of servers and thousands of VM to be fastly directed. Besides, it secures management by means of specific placement rules. These rules notably enable a specific set of VM to be forced to run on a particular set of servers (and vice-versa). In addition, they can be used to prevent VMs from coexisting on a set of servers or to group VM on such a set.

Using a language to manage a large-scaled infrastructure provides an interesting alternative to VM managers. Indeed, it enables the administrator to use scripts and to manipulate large sets of elements. The language has been classified using three administration sub domains: infrastructure description, elements selection within an infrastructure and reconfiguration of a virtualized infrastructure.

1. Data center views description

The infrastructure description is used to build an internal representation of the substructure in the administration tool. This description includes much information about the way resources are organized in the infrastructure. This information will be used by the infrastructure management language to select elements efficiently and to simplify infrastructure reconfigurations.

An infrastructure such as a data center must be viewed from different angles to be easier to administrate. For instance, a physical view enables the data center to be described according to its physical architecture: a server X is in an array B, which is in the corridor C in the room R of the DC data-center in the town T.
An electrical view shows that the plug P is connected to the circuit breaker CB of the low-voltage distribution board L, powered by the input A. These views are generic and can be set depending on the use context of btrCloud.

Once they have been described, an administrator can easily manipulate these abstractions and determine, for instance, the instant consumption of the servers connected to the CB circuit breaker. For this purpose, he will use the language provided by the btrScript software package, which is introduced in the next subsections.

2. Browsing views

Each element of a data center (plug, server, array) gets a type during the infrastructure description. These types are linked to one another to create a consistent hierarchy of elements. All the sons of an element can be retrieved from this typed hierarchy, using the “/” operator. This operation is called browsing. Consider the following type hierarchy : town -> center -> array -> server. An element of type “town” includes elements of type “center” that represent data centers, which are composed of array that themselves include servers.

Selecting all the “town” elements can be down using the “/” operator:

> nantes, lille 
All the sons of an element can be retrieved by browsing the type. For instance, getting all the sons of type “center” of the site “nantes” is done by the following browsing:
> emn-center, polytech-center
The answer shows that there are two data centers in Nantes. This browsing is called “direct” because the type “center” follows the type “town” in the hierarchy. “indirect” browsing is allowed as well. The types in between are then omitted. For instance, the list of all servers of the “emn-center” data center can be retrieved by the following browsing:
> kvm1, kvm2, kvm3, kvm4
The server names are thus retrieved, and can be used for browsing purposes. In the above examples, browsing begin from a father element to reach son elements. As browsing are bidirectional, it is possible to know which site hosts the server “kvm1” using the following command:
> nantes
During a son/father browsing, a single element will be retrieved. Indeed, whereas a father can have several sons, a son only has a unique father. Browsing is also used to cross bridges, and therefore to browse between views. Let us add to our example a second view including VMs with the hierarchy : user -> vm. A bridge between types “server” and “vm” is created to symbolize the hosting connection between a hypervisor and its VMs. All the VMs on a server can be listed using direct browsing:
> vm1, vm4
Indirect browsing can be used to retrieve all the servers used by the user “invite1”:
> kvm2, kvm3

3. Building sets of elements

It is necessary to build a set of elements to perform introspections of reconfigurations on several elements. For this purposes, the “[]” operator enables several elements to be selected based on their names. Enumerations can be expressed through this operator to select elements with similar names. For example, the elements “server1”, “server2”, “server3” and “server4” are selected using the following expression : server[1-4].
The “[]” and “/” operators can be used together in the same expression to create a set:

[ nantes/server & invite[1-2]/server ]
The administrator can select large sets of elements using set building operators. These elements will then be used to retrieve information about the infrastructure and to reorganize resources. Selecting all the elements with a common name part can be done by means of the “*” character.

4. Operations on sets

The “[]” operator suggests building sets from traditional operations on sets for elements with radically different names. All the following expressions only select the servers “server1”, “server2”, “server3” and “server4”:

5. Properties management

Property name Definition
cpu Processor size
cpu_nb Number of processors (for servers) or of CPU (for VM)
cpu_cons CPU consumption in percent
cpu_free Available CPU amount in MHz
mem Memory size
mem_cons Memory consumption in percent
mem_free Amount of free memory in MB
power_cons Electricity consumption
power_min Minimal electricity consumption of a server
power_max Maximal electricity consumption of a server
mac MAC address
ip IP address
The administrator can consult a property by using the “:” operator. For instance, the CPU consumption of the server called “server1” can be retrieved with: server1:cpu_cons. Consulting a property which does not exist or does not have any value returns “empty”.
For the model flexibility to be guaranteed, properties can be added and modified by the administrator after the model has been built. This allows the evolution of the infrastructure to be taken into account.

6. Filters and selections

Properties associated with elements can be used to select one or several elements more accurately. Indeed, filters can be used to select one or several elements from a previously selected set. For instance, selecting all the servers that have a hypervisor is done through the “==” operator, as follows:

\server{role == hypervisor}
Functions can also be used to select elements with common properties. For example, selecting servers with the highest and the lowest CPU consumption, respectively, is done with the following commands:
The second parameter of the “max” and “min” functions stands for the number of elements to select. For example, the three VMs with the most memory can be done by using the following expression:
Filters based on the structure of the infrastructure is possible as well. Thus, the administrator can select all the servers that host at least one VM:
\server{size(vm) > 1}

7. Actions

In btrScript, creating a disk image of a new VM is done through a copy of a previously created model disk image:

In order to simplify the syntax of VM creation operations, the information required for initializing VMs is described in a VM model called “template”. This model includes the number of VCPUs, the memory and a model of the disk image to copy. Thus, only an element name and a VM model need to be specified to create a VM. Creating a VM does not start it and thus does not consume resources. Still, it saves every property of the VM to allow its boot:
If no server is given to the “start” operator, the VM is booted on the server it has been created on. If there is a share between several servers, the VM can be booted on one of them. In this case, a server can be specified while booting:
vm1:start server2
Other available actions are:
Managing applications on a running VM or server can be done with the “exec” that runs commands on the VM. Then, the administrator can run or stop applications like a tomcat application server:
A VM can be migrated using the “migrate" operator:
vm1:migrate server2

8. Placement rules

The “on” rules will force a set of VMs to be executed on a set of servers. Then, the administrator can force VMs to be executed on the most powerful machines. The following rule forces the VMs “vm1”, “vm2” and “vm3” to be hosted by the servers “server1” or “server2”.

vm[1-3] on server[1,2] 
The “noton” rules force a set of VMs not to be executed on a set of servers. It simplifies the writing of “on” rules. If the administrator wants to force a VM to be executed on all servers of the infrastructure except one, it will be easier to describe the server on which the VM shall not be executed.
vm[1-3] noton server1 
The “spread” rule prevents VMs from coexisting on the same server. It enables breakdown tolerance policies to be set up. If a service is provided by three VMs, the administrator must ensure that these three VMs run on distinct servers. If one of these servers breaks down, the service is still offered by two VMs. The following rule prevents the VMs “vm1”, “vm2” and “vm3” from coexisting:
vm[1-3] spread 
The “group” rules group VMs on a single server. For efficiency purposes, the administrator can group VMs that communicate with one another over the network. The following rule groups the VM “vm1”, “vm2” and “vm3” on the same server.
vm[1-3] group

9. Placement rules management

The administrator can use four operators to manage placement rules:

Using placement rules, the administrator specifies the organization of elements to express accurate needs. However, these rules do not generate reconfigurations, which need to be performed by the administrator at the right moment.

Placement rules can be automatically enabled or disabled:
[00:6:14:4:12:*] vm1 on server1
[00:6:*:*:*:5,6 - 00:20:*:*:*:5,6] vm2 on server2
The first rule will be activated on April 14th 2012 at 6 am. The second one will be enabled at 6 am and disabled at 8 pm each Saturday and Sunday. Each programming uses the following syntax :
mm hh jj MM JJ my_task
mm: schedule minutes
hh: schedule hours
jj: schedule day
MM: schedule month
JJ: schedule weekday (for instance, 5 stands for Friday)

Each field can use the following notations:
*: each unity (0, 1, 2, 3,..., 8, 9);
5,8: unities 5 and 8;
2-5: unities from 2 to 5 (2, 3, 4, 5);
*/3: every three unities (0, 3, 6);
10-20/3: every three unities between 10 and 20 (10, 13, 16, 19).

10. Calls to the optimization module

In a large-sized infrastructure, it can be difficult for the administrator to solve several simultaneous overload issues, for instance in case of an high increase of VM consumptions. In that case, the “solve” operator suggests to the administrator to use placement algorithms which compute the required actions to solve the overload issues :

This operator uses as a parameter the name of the algorithm to use. The administrator may try to solve the overload issues by using a specific scheduling policy, depending on the selected algorithm. In the previous example, the “checker” algorithm enables the overload issues to be corrected with as few reconfigurations as possible. Setting up a scheduling policy such as load-balancing or consolidation becomes really complex for a large infrastructure with an important amount of VMs. The “load-balancing” and “consolidation”