Getting a VM’s IP address sounds like it should be the easy part of an automation project. In my VCF Automation lab, it turned into one of those small details that consumed far more time than expected.
First some background on my lab environment. Using Holodeck I deployed a single Management Domain, Supervisor, Automation. On top of that I added a single All Apps Organization.
My goal was simple: Deploy an All Apps Organization virtual machine through a CCI.Supervisor.Resource, wait for the VM and its guest network to be ready, and return the assigned IPv4 address as a deployment output. I found an example that pointed me toward status.network.primaryIp4. It was close—but close does not count when a property name is case-sensitive.
My ultimate intent here, is to use that IP address or addresses as part of a three tier application blueprint. But that is another blog.
The path that worked in my environment was:
status.network.primaryIP4
The IP is uppercase. That capitalization was the difference between an empty or unusable value and the address I needed.
Following the VM’s actual status
The breakthrough came from looking at the status returned for the deployed VM instead of continuing to guess at the schema. The VM’s status.conditions array showed the conditions it passed through as provisioning progressed. The same status object exposed the network data under:
status: network: primaryIP4: 192.0.2.25
The lesson here is simple: Use the object returned by your own VCF Automation and VM Operator version as the source of truth. Blog posts and examples are useful starting points, but a small schema or capitalization difference can break a binding expression.
Steps to finding that information.
- Deploy the machine
- View YAML on the machine page
- Walk the properties (I collapsed several sections to enhance readability). Here the path to primaryIP4 is
status.network.primaryIP4.
How to find the conditions
Follow the same logic as finding primaryIP4. You will find the conditions or stages the machine went through along with the ‘status‘ and 'reason‘.
Why the wait block matters
Reading the right path is only half of the solution. VCF Automation also needs to wait long enough for the Supervisor resource status to contain the network information.
Broadcom documents a status-collection race in VCF Automation 9.0.x. Without an explicit wait, the resource can be considered created before its reconciled status has been synchronized back to Automation. Broadcom’s minimum recommendation is to wait for VirtualMachineCreated=True.
For my blueprint, I waited for VM creation, VMware Tools, guest network synchronization, and a value matching an IPv4 pattern:
resources: Supervisor_VM: type: CCI.Supervisor.Resource properties: context: ${resource.Supervisor_Namespace.id} manifest: apiVersion: vmoperator.vmware.com/v1alpha5 kind: VirtualMachine metadata: name: ${input.vmName} spec: # The rest of the sanitized VM manifest goes here. wait: timeoutSeconds: 1800 conditions: - type: VirtualMachineGuestNetworkConfigSynced status: 'True' reason: Synced - type: VirtualMachineCreated status: 'True' - type: VirtualMachineTools status: 'True' jsonPath: - path: '{.status.network.primaryIP4}' regex: \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3}
Return the address as a blueprint output
Once the wait completes, the address can be exposed as a deployment output. With the resource named Supervisor_VM, the binding is:
outputs: vmIp: type: string title: VM primary IPv4 address value: ${resource.Supervisor_VM.object.status.network.primaryIP4}
Again, the working property is primaryIP4, not primaryIp4.
This output can also be consumed by another resource binding. For example, an application VM could receive a database VM’s address during cloud-init. Make sure the upstream VM’s wait block completes before relying on that value.
Validation
After deploying a new version of the blueprint:
- Confirm the deployment completes without a wait timeout.
- Inspect the
CCI.Supervisor.Resourceobject and verify thatstatus.conditionsincludes the expected successful conditions. - Verify that
status.network.primaryIP4contains the VM’s address. - Confirm the deployment output shows the same address.
- From an appropriate network location, test the service that should be listening on that address.
The last step matters. VirtualMachineCreated=True, synchronized guest networking, and a populated primaryIP4 prove that the platform has an address for the VM. This does not prove that cloud-init finished successfully or that the application inside the guest is healthy.
Here is a screenshot of a deployed machine with the output vmIp set to 10.2.0.2.
The finished blueprint
The blueprint used in this blog is available here, VCF Automation Supervisor VM IP Discovery on GitHub
Take Aways
- Leverage AI to do the heavy research. One of the responses gave me the thought to check that case sensitivity.
- AI, also mean’s ‘Ain’t Intelligent’. It WILL send you down the wrong path eventually. As the developer you still need to know what it SHOULD like in the end.
- AI, also mean’s ‘Ain’t Intelligent’. Trust but Verify.
- Don’t get in a hurry. I worked on this on and off in my ‘spare time’ for a few days. Then finally it clicked at the end.
- All Apps Organizations are a new construct for most of us. The available public content and samples are few and far between. Please, Please, Please take some time to share your lessons learned with the community.
References
- VM Status Information Missing in VCF Automation 9.0.x Deployments (Broadcom KB 435137)
- VMware Cloud Foundation Automation: Cloud Consumption Interface in Templates
Nuff for now. Happy automating.
knotacoder.com 