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 apt.
- The version of i-doit is 1.7.1 or higher. The i-doit host is accessible via the FQDN i-doit.example.net.
- 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 vmprovision with the password vmprovision.
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:
1 2 3 4 5 6
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 apt and cpan:
1 2 3
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 http_proxy and ftp_proxy:
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:
1 2 3 4
For 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:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183 184 185 186 187 188 189 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223 224 225 226 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 277 278 279 280 281 282 283
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 provisioned (see below)
- $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.
- Event: Category: (arbitrary sources) Save
- Description: VM provisioning
- Type: SHELL COMMAND
- Command: /usr/local/bin/i-doit_provision.php
- Additional parameters: leave this blank
- Mode: Executive live
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.
In the 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.
In the 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).