vRealize Orchestrator is VMware’s automation and workflow engine that unlocks the true power of vRealize Automation enabling things like custom machine provisioning/de-provisioning steps and any external systems that may need to be called
For those still using vCenter Orchestrator 5.5, the appliance seems to have one strange issue that might impact those making changes to the underlying infrastructure. The appliance has an odd tendency to revert DNS to the previously provisioned values even after changing them in the configurator. This issue has been documented here (vCO v220.127.116.11) and, to a lesser extent, here (vCSA). The information provided by VMware in the release notes to vCO is correct except for one important detail—the appliance must be power cycled (not rebooted) to re-read and re-apply the new DNS IP information.
When vCO and certain other appliances are deployed initially with static IP information, OVF properties are created specific to that VM which get saved and applied when it first boots to speed time of deployment. It is visible after editing settings on the VM and checking the vApp Options tab:
If the DNS server information needs to be changed thereafter, normally the web-based interface (VAMI) listening on port 5480 is used to change this info, but although the new DNS IP will be updated and used immediately by the system, after a reboot the appliance will revert to using the originally-configured IP. This could render the vCO/vRO appliance useless if it has been configured to talk to external services (AD, SQL, etc.) via name and not IP. The best way to change DNS if required is to change the DNS IP in the vApp Properties (the VAMI may still be used if the new IP is needed immediately) and then power off/power on the appliance. A simple guest restart of the appliance will not work and it will come back with the last DNS IP that was configured before the last power cycle.
In short, IP settings may be changed in the VAMI to take immediate effect. vApp properties, if specified at time of deployment, are read ONLY at time of boot and are not updated automatically. The vApp properties will override the VAMI properties. In order to have changes in the VAMI persist, one must change them in the VAMI, change them identically in the vApp properties, then shutdown and power on the appliance.
*Note: that this bug does not affect version 6.x of vRealize Orchestrator, and the vApp properties are read only upon first boot of the appliance. Thereafter, any changes made in the VAMI will persist after both guest reboots and virtual machine power cycles.
Chip Zoller joined Sovereign Systems as a Solutions Architect on the virtualization and cloud team in mid-2015 and brings many years of expertise in various fields of IT. Prior to that, he worked for several large enterprise customers designing, building, managing, and optimizing their virtualized infrastructures on multiple VMware products and platforms. A deep technologist at heart with a passion for virtualization and complex problem solving, he also is a classically trained musician and, when not researching and experimenting with new technology, curates and contributes to the world’s largest online music score library. He holds a Master’s and Doctorate degrees from the University of Georgia and Louisiana State University, respectively.