Some virtual machines have “custom properties”, and the only way you can know about these in-advance, is if you examine the OVF file itself, or load the image (OVA/OVF) to the vCenter GUI manually. Fortunately, as part of our process, we tend to always load the image up manually as a first step. And recently, we came across the Cisco CSR1000v image, which is a Virtualized Networking Function (VNF). We noticed when we loaded this image, it asked you to select “flavor” (borrowing the term from OpenStack, which means sizing essentially). There was a Small/Medium/Large prompt. Once you passed that, and you went a couple of steps further, we encountered a page full of properties that you could set on the virtual machine (Router Name, Management Interface, IP settings for the management interface, etc).
I had not seen this before, and learned that these are “Customization Profiles” that VMWare introduced. This customization profile, was embedded into the VM, so that you could establish network reachability and avoid having to manually connect to the CLI through the console, and configure up the initial “bootstrap” settings of the virtual machine.
VMWare introduced these Customization Profiles (or Customization Specs as they’re also called), and their vRealize Automation tool does allow you to set these as part of their provisioning orchestration workflows. The problem for us, was that Morpheus does not support these . Further complicating things, Cisco does not run Cloud-Init or VMWare Tools on these images (any VM running on VMWare really should at least be running VMWare Tools).
We recently prototyped a solution to get the properties injected into the VM, using a tool called Common OVF Tool (cot). We learned about COT as we were reading the configuration guide for the Cisco CSR1000V.
I will attach that link here for reference:
CSR1000V Configuration Guide
Common OVF Tool is found on GitHub, at this location:
Common OVF Tool
Here are the steps to getting this working:
-
The first thing to do, is to install the Common OVF Tool on the Morpheus Appliance. COT is a Python utility, so I used pip to install cot. Since I am running CentOS7, I simply ran “pip3 install cot”. I noticed that the installation drops the invoker (cot command shell or binary) in /usr/local/bin, which may or may not be in your path.
-
I then added a new Morpheus Layout for the CSR1000v Instance Type, called “Workflow COT Deploy”. In this layout, I put all of the Option fields to capture all of the same properties that I saw in vCenter when I loaded the image there. Lastly and most important, is the type field. The type field for us, is usually VMWare (because we deploy to vCenter clouds). But in this case, the type needed to be “Workflow”. When you make a “Workflow” type of instance type, all of the cloud-specific provisioning gets skipped. It allows you to just “run a script” - nothing more, nothing less.
-
Next, I created a Task in Morpheus. I created a Bash shell script task. The bash shell script grabs the variables from the Morpheus input fields. Initial versions of the script just dumped these to the console window and attempted to call cot to inject the captured properties into the OVF. You can alter an existing OVF, but my script made a copy of the OVF (leaving the original intact) and attempted to inject the properties into the copied OVF.
-
Next, I once I got the script injecting the properties, I created a Workflow, and and added the Task to Pre-Provisioning stage of the workflow.
-
I then tested the script by launching the instance type, and choosing the Workflow Layout. Indeed it did call my bash script just fine.
At this point though, I had only injected the properties into the VM. I had not actually wrote any logic to push the OVF to vCenter. This could be done so many ways. You could use Powershell and PowerCLI to do this, you could call OVFTool to do this, or even make direct API calls to either Morpheus or vCenter. But the Common OVF Tool has a “cot deploy” command, that in turn uses OVFTool to deploy the VM, and we elected to test that, and if it worked, use that method to keep things simpler.
- Next, we changed the script to call “cot deploy” and the first time we ran it, it failed because OVFTool was not installed. So, we downloaded OVFTool (zip file), and ran the installer to get it installed on the Morpheus appliance. Then we re-tested the script, and sure enough, the VM deployed to vCenter.
Note that we used version 4.4 of the OVF Tool. I think their newer 4.5 version of OVFTool is for vSphere version 8!
So now, we have a means to deploy a Virtual Machine that has custom properties. There are some limitations, but it can be done. Some of the limitations we encountered, include:
-
Using this Common OVF Tool, we could not figure out how to specify a folder to put the VM into. As a result, the VM is pushed to the base folder in vCenter. As a practice here, we like to put all of our Morpheus VMs in a “Morpheus Managed” folder so as to distinguish VMs managed by Morpheus from those deployed outside of Morpheus. So to get around this, we wrote up a Powershell / PowerCLI script that soaks in the Morpheus variables (vCenter url, vCenter credentials, instance name), and calls PowerCLI to move the folder. This was added as a 2nd subsequent task following the bash script that sets the properties and deploys the VM.
-
Once you deploy the VM in this manner, it will run successfully and “look” like a VM has been deployed. But the resultant VM you deployed is not a Morpheus Managed VM, it shows up as a Discovered VM in Compute/Host/VMs. You will need to fish the VM back by doing a “Convert to Managed”, manually. And if you do this, you have to probably delete the workflow deployment you just ran, because it wouldn’t be necessary anymore at that point. A bit klugic perhaps if you want a more elegant deploy as is typical with Morpheus VM deployments.
But, I did want to do a write-up discussing this utility, and the fact that it did give us an automated means to push a VM with Properties to Morpheus.