In this article, we examine the use case of provisioning virtual machines (VM) via i-doit. For this purpose, we utilize a well-maintained IT documentation paired with a few scripts to make this automation a reality.
Up until now, documentation and configuration files are strictly distinguished: The organization-wide IT is documented in i-doit, including a virtualization cluster. This cluster consists of multiple virtualization hosts (host systems) and the virtual machines running there (guest systems). The configuration of each VM is executed within the administration environment of the cluster. This includes the creation of a new VM with specific settings to CPU, memory, network, disk space and so on. This process is also called provisioning.
For the daily routine, this means that the process is characterized by a dedicated tool which creates a new VM. Subsequently, the completed work is documented in i-doit:
- Start the configuration tool of the virtualization cluster
- Create and configure a new VM
- Switch to the IT documentation (i-doit)
- Create a new VM, configure the respective categories, assign the VM to the cluster
There is no data exchange between the applied tool and i-doit, thus the VM configuration has to be performed twice. Errors cannot be ruled out when transferring the configuration. The redundant maintenance of configuration files is therefore a very thankless task for the admin.
This article is outdated and no longer current
Please note that the procedure described here may already be outdated.
We wish to optimize this process by using the configuration files available in i-doit and by automating some of the steps. With this in mind, we change the process:
- Open the IT documentation (i-doit)
- Create a new VM, configure the respective categories, assign the VM to the cluster
- The VM will be created and provisioned automatically in the configuration tool of the virtualization cluster
Four manual steps become two. The third step is carried out automatically in the background. The doubled maintenance of the configuration files by the admin can be omitted. Error sources are eliminated and the admin is happy.
We will completely go through this use case with an example. This is supposed to show the general procedure and can be applied easily in other environments. For the solution we assume:
- The virtualization cluster is based on VMware vSphere in version 5.
- i-doit is installed on Debian GNU/Linux 8.5. For this, we use the Eval Appliance. The distribution packages should be updated with
- The version of i-doit is 1.7.1 or higher. The i-doit host is accessible via the FQDN
- To monitor the automation we use the VMware vSphere client.
- A user exists in VMware vSphere who has the permissions to provision VMs. In our example this user is called
vmprovisionwith the password
First of all, we have to carry out some preparations so that both systems are able to communicate with each other.
We require VMware SDK for Perl on the i-doit host so that i-doit can inform the vSphere cluster to provision a new VM. Therefore we download version 6.0.2. For this purpose, you need an account at VMware and you have to accept the VMware End User License Agreement (EULA). We decide to download the package as Tarball (.tar.gz) for 64bit operating systems.
After downloading, we copy the Tarball to the i-doit host and extract it. We will log in as root since the root permissions are necessary for almost all of the following commands:
At this point, it is a good idea to bring the system up to date - if you have not already done so. We also install additional packages via
Since the SDK does not support Debian GNU/Linux officially, we will need to trick the SDK into thinking it is a different operating system:
The SDK needs the environment variables
Now we install the SDK by utilizing the provided installation script:
The script once again needs to have the EULA of VMware confirmed with
yes. If additional Perl modules are to be installed, you should also confirm this with
yes. Once the installation was completed successfully, the following text appears as part of the output:
At this point, the installation of the SDK is completed. We followed these guidelines. Thank you very much! And now we continue with the next step.
Part of the communication between i-doit and VMware takes place via the API of i-doit. The API has to be activated and you need to know the API key. To use the API comfortably we use the reference client for PHP:
make initialize the API client queries the URL and the API key of the i-doit installation that is going to be used.
The following script represents the link connection between i-doit and VMware:
We copy this to the
/usr/local/bin/i-doit_provision.php file. We also assign the appropriate permissions so that the Apache web server is able to run the script:
This script includes the configuration to access both i-doit and VMware. It has to be adjusted accordingly:
$vSphereUsername: User for vSphere (see above)
$vSpherePassword: Password for vSphere (see above)
$vSphereWebService: URL to the Web Service of vSphere
$objCMDBStatus: ID of the CMDB status
to be provisioned(see below)
$objCMDBStatus_ready: ID of the CMDB status
$api_entry_point: URL to the API of i-doit
$api_key: Key for the i-doit API
Supplement CMDB Status
The two CMDB status statements
to be provisioned and
provisioned do not exist in the i-doit default installation yet but they are crucial for the automation. They need to be supplemented as described in the linked article.
Now i-doit has to be configured to execute the script if certain changes are performed. For this, we use the event controls and create a new hook.
Category: (arbitrary sources) Save
Additional parameters: leave this blank
At this point, the configuration is finished and the automation is "activated".
After this extensive one-time configuration we can now take a look at how the automation works.
Document the Virtual Environment in i-doit
A vSphere cluster (object type
Cluster) with some ESX hosts (object type
Virtual Host) already exists. The object title of the cluster corresponds to the datacenter in vSphere. The object titles of the ESX hosts are the host names which are also displayed in vSphere.
Virtual switches are configured with VLAN IDs (category
Virtual switches) for each ESX host.
The ESX hosts are bound to a central storage which supplies the VMs with disk space (category
Logic devices (Client)).
The storage side is construed accordingly. The
Logic devices (LDEV Server) category contains the assignment of LUNs to ESX hosts.
Create New VM
The vSphere Cluster and the storage are now ready according to the IT documentation. It is time to document VMs – and provision them automatically.
First you create a new VM (object type
Virtual server) and set its CMDB status to
planned (since it does not exist yet).
Afterwards, the desired system configuration is documented. The number of demanded CPU cores is documented in the
CPU category. One entry is generated for each core.
The required RAM is documented in the
Memory category. Number of RAM modules and the chosen value units are not important. The total capacity is summed up instead.
Network → Port category the title of the first entry is used to configure a virtual port for the VM.
The required disk space is specified in the
Direct Attached Storage → Device category.
Virtual machine category you document in which cluster and on what ESX host the VM is supposed to run.
The assignment of storage and network is stored in the
Virtual machine → Virtual devices category. The screenshot shows which attributes should be filled in.
With this the configuration of the VM is sufficiently documented.
A template is useful to document virtual machines faster and thereby provision them faster. A template is created for each pre-assembled VM and new objects are generated on basis of this template.
Provision VM Automatically
Now we come to the final step: the provisioning. We do not have much left to do. In the
General category the CMDB status is set to
to be provisioned. When the change is saved, the script described above starts to read the configuration files from i-doit and transfer them to vSphere. Saving may take some time as the results need to be there first.
Once the provisioning has finished successfully, the CMDB status is automatically changed to
provisioned. The VM has been created and runs. Done!
The communication between i-doit and vSphere is displayed at
Administration → CMDB settings → Events → History (Log).