When deploying a fresh standalone VCF Operations Orchestrator 9.0.2 appliance, integration with VCF Automation fails, and the appliance becomes stuck during its initial boot cycle.
Reviewing the appliance via SSH or the vCenter Web Client console surfaces the following symptoms:
The guest OS boot sequence stops and displays an explicit failure: run-bootstrap.service failed.
Checking the local Kubernetes environment with kubectl get pods -n kube-system indicates that all three state-enforcement-cron pods are in an Error state.
Inspection of the pod error logs via kubectl logs <state-enforcement-cron-pod-id> -n kube-system shows:
failed check /usr/bin/systemctl is-active run-bootstrap.service: exit code: [3], stdout: [failed]
Reviewing the systemd journal for the bootstrap process (journalctl -u run-bootstrap.service) isolates the following error trace:
Waiting for local-infra timed out: curl: (6) Could not resolve host: <shortname>
Standalone VCF Operations Orchestrator 9.0
This issue occurs when the DNS servers fail to resolve the configured short hostname of the newly deployed appliance.
During the initial firstboot cycle, the appliance triggers a localized infrastructure mapping script (/etc/bootstrap/firstboot.d/02-setup-kubernetes). This orchestration script utilizes a curl lookup against its own assigned shortname/hostname to map and tie its internal Kubernetes orchestration network together. If the network DNS servers cannot resolve this hostname, the curl check times out and exits with error code (6) Could not resolve host. This terminates the run-bootstrap.service unexpectedly and blocks the core system pods from completing initialization.
To resolve this issue, the underlying network DNS bindings must be corrected before re-executing a clean appliance deployment.
Log into the primary DNS Management Server.
Create a new Forward Lookup (A) record mapping the short hostname and its Full Qualified Domain Name (FQDN) to the static IP address allocated to the appliance.
Ensure a matching Reverse Lookup (PTR) record is also created in the corresponding subnet zone.
Open a command prompt on an external machine on the same network subnet and verify proper resolution using:
nslookup <Appliance-Hostname>
Because the initial bootstrap script failed mid-process, the internal configuration files and database layers are in an unstable state. A clean deployment is required:
Log into the managing vCenter Server web client.
Locate the failed VCF Orchestrator virtual machine, power it down, and Delete from Disk.
Redeploy a fresh instance of the VCF Orchestrator 9.0.2 OVA template. Ensure the networking properties exactly match the hostname and IP configurations defined in your DNS server in Step 1. Refer to Deploying VCF Operations Orchestrator.
Power on the newly deployed appliance.
Monitor the console screen or open an SSH session into the new appliance once it becomes reachable.
Confirm that the firstboot scripts clear without flagging errors. You can track namespace initialization by executing:
kubectl get pods -n <namespace> (list all the namespaces using 'k get ns' command)
Once all the pods register a healthy status, proceed with your standard VCF Automation integration workflows.