The automatic and unattended installation of virtual machines can be achieved with several techniques. In this series, I´ll show the approach of using CloudInit together with VMware Aria Automation Orchestrator. This will be realized by the use of Guest OS Customization of the specific VM.
In Part 3 we´ll be finally deploying some VMs with a new designed workflow.
The deployment Workflow
The workflow to deploy new VMs mainly consists of the following steps
- Prepare the GET call to our web server to fetch the metadata
- Execute the GET call and store the returned data
- Prepare the GET call to our web server to fetch the userdata
- Execute the GET call and store the returned data
- Clone a new VM from one of the previously created templates
- Apply the meta- and userdata to the new VM
- Start the VM and let cloud-init do its job
Variable Naming
To make it easier to match all the used variables in this workflow, following naming rules apply
| Variable Prefix | Variable Type |
| in_ | Input |
| out_ | Output |
| var_ | Variable |
Variable Definition
Inputs/Outputs
| Variablename | Type | Usage |
| in_IpAddress | string | IP for the new VM |
| in_DefaultGateway | string | Default Gateway for the new VM |
| in_Hostname | string | Hostname and VM name for the new VM |
| in_Domain | string | DNS searchstring for the new VM |
| in_DNS | Array/string | DNS servers for the new VM |
| in_CIDR | string | netmask as CIDR value for the new VM |
| in_VmTemplate | VC:VirtualMachine | Source Template for the new VM |
| in_DestinationVmFolder | VC:VmFolder | vSphere Folder where the new VM should be placed |
| in_EsxiForDeployment | VC:HostSystem | ESXi Host to run the new VM |
| in_ResourcePoolForDeployment | VC:ResourcePool | ResourcePool of the running ESXi host |
| in_DatastoreForNewVm | VC:Datastore | Datastore where the new VM should be stored |
Variables
| Variablename | Type | Predefined value | Usage |
| var_boolFalse | boolean | false | bool which is always “false” |
| var_boolTrue | boolean | true | bool which is always “true” |
| var_newVM | VC:VirtualMachine | Variable to store the Object of the new VM | |
| var_metadata | string | Variable to store the metadata string | |
| var_userdata | string | Variable to store the userdata string | |
| var_url | string | Variable to store the URL for the GET calls to fetch metadata and userdata |
The workflow setup
Prepare metadata
The “prep metadata” script block will be fed by all needed variables as Input variables
We take all input variables and connect them to one large string which will fill “var_url”.
The actual script block looks like this
var_url = "http://<ip of web server>/metadata_linux.php?";
var_url += "hostname="+in_Hostname;
var_url += "&ip="+in_IpAddress;
var_url += "&cidr="+in_CIDR;
var_url += "&gateway="+in_DefaultGateway;
var_url += "&dns_search="+in_Domain;
var_url += "&dns1="+in_DNS[0];
var_url += "&dns2="+in_DNS[1];
Get metadata
To get the metadata a simple “HTTP get” workflow from the “Network” module is used.
It gets the just filled “var_url” as input and will save the returned string to “var_metadata”.
Prepare userdata
As the userdata is all hardcoded in this example we only need to change “var_url” with the information to get our encoded string. Therefore “var_url” is the only Input/Output Variable that is connected with this script block.
The scriptblock is also quite easy to understand.
var_url = "http://<ip of webserver>/userdata_linux.php";Get userdata
To get the userdata we almost use the identical workflow as for the metadata, we only change the output to “var_userdata”.
Clone virtual machine
To clone one of our templates and use it as a new VM for our Guest Customizations we use the built-in workflow “Clone virtual machine, no customization”. The variables are set as the screenshot shows.
Apply metadata and userdata to the new VM
This script block has the first real lines of Orchestrator code in it.
It will create the needed Advanced Settings and store the fetched data inside them.
As Input variables, we need our new VM Object, the metadata and the userdata strings.
The script will create a new empty ConfigSpec to which we add our variables.
At the end, we apply the ChangeSpec to our VM object.
var spec = new VcVirtualMachineConfigSpec();
var extraConfig = new Array();
extraConfig[0] = new VcOptionValue();
extraConfig[0].value = 'gzip+base64';
extraConfig[0].key = 'guestinfo.userdata.encoding';
extraConfig[1] = new VcOptionValue();
extraConfig[1].value = 'gzip+base64';
extraConfig[1].key = 'guestinfo.metadata.encoding';
extraConfig[2] = new VcOptionValue();
extraConfig[2].value = var_Userdata;
extraConfig[2].key = 'guestinfo.userdata';
extraConfig[3] = new VcOptionValue();
extraConfig[3].value = var_Metadata;
extraConfig[3].key = 'guestinfo.metadata';
spec.extraConfig = extraConfig;
var deviceChange = new Array();
spec.deviceChange = deviceChange;
var_newVM.reconfigVM_Task(spec);
Start VM and wait
The last step of our workflow is an out-of-the-box item again.
To boot our new VM with the new settings we use the “Start virtual machine and wait” workflow and pass our VM object to it, along with the ESXi Host on which the VM should be started.
Let´s testdrive the whole setup
Execution of the workflow
To test the new workflow I´ve used the settings as on the screenshot. In my case I deployed a new RHEL9 VM with it.
In my lab, the whole execution including cloning and startup takes around 78 seconds.
As we used the “Start virtual machine and wait” the workflow should end as soon as the OS has booted up, including all the changes done by cloud-init.
Let´s verify if everything went smooth
The first and fastest spot to see if the metadata part worked is our vCenter.
When looking at the DNS name and IP addresses of the new VM it seems this step worked fine.
To verify the userdata part I now tried to log in to the VM via putty and my ssh-key.
This also seems to work.
After the successful log in I tried my sudo rights, which succeeded and not… (the rights were fine, but as the system hasn’t been registered with Red Hat yet the command failed).
Troubleshooting
If cloud-init should fail, you should log in to the VM via VMRC and check the cloud-init logs.
Those can be found at /var/log/cloud-init.log and /var/log/cloud-init-output.log
All my failures could be explained from these both files. Most of the time it failed due to malformed YAML code or invalid variables passed to the VM.
That´s the end of part 3 and also the end of this mini-series.
If you have any remarks are questions drop a comment or mail.
Leave a Reply