vCenter Operations Field Notes

A VM can have the correct FQDN intent and still receive the wrong resolver search suffix. The trap is treating these as the same setting: vm_domain -> identity/FQDN domain dns_search -> resolver search suffix list They are related, but they are not the same control. Symptom An environment sets DNS search suffixes to empty: dns_search = "[]" But new vSphere VMs still boot with a resolver search domain such as: search corp.example.com The node audit shows drift even though the Terraform input looked correct: ...

Importing existing vSphere VMs into Terraform can produce a clean source-of-truth checkpoint and still leave a plan that should not be applied. That is common when legacy Kubernetes nodes were built from an older template or outside the current module conventions. Audit Checkpoint A useful checkpoint looks like this: NetBox resources: no-op vSphere resources: update destroy actions: none This means NetBox ownership is reconciled, but Terraform still sees vSphere drift. ...

After existing vSphere VMs are imported into Terraform state, expect drift. The question is not whether drift exists. The question is whether applying that drift is safe. Generate The Audit Plan terraform plan -out=audit.tfplan terraform show -json audit.tfplan \ | jq -r '.resource_changes[]? | [.address, .type, (.change.actions | join(","))] | @tsv' Start with action types: no-op update create delete delete,create For imported production-like nodes, any delete, create, or delete,create action needs explicit review before apply. ...

NetBox has more than one way to represent infrastructure. A VMware VM imported as a DCIM device may look usable in the UI, but it is not the same object model as a NetBox virtualization virtual machine. Terraform provider resources for NetBox virtualization expect the virtualization model. Symptom A known VM does not show up through the virtualization endpoint: curl -s \ -H "Authorization: Token $NETBOX_TOKEN" \ -H "Accept: application/json" \ "$NETBOX_URL/api/virtualization/virtual-machines/?name=$VM_NAME" \ | jq '.count' Expected if it is modeled as a virtualization VM: ...

Use this workflow when existing vSphere VMs need to be brought under Terraform state for audit and future lifecycle management. The first goal is not to change the VMs. The first goal is to make Terraform aware of them and classify drift. Safety Boundary Set the operating rule before importing: Import state and audit only. Do not apply full vSphere changes to existing cluster nodes. This avoids turning a state migration into an accidental infrastructure mutation. ...

After Terraform creates or resizes a vSphere VM, verify NetBox reflects the same lifecycle state. This check is separate from preflight. Preflight prevents unsafe allocation before apply. Post-provision verification proves source-of-truth state matches what Terraform just changed. Set Lookup Values Use generic environment variables so the commands are reusable: export VM_NAME="cluster-a-app-01" export VM_IP="192.0.2.10" export VM_DNS_NAME="cluster-a-app-01.example.com" export NETBOX_CLUSTER_NAME="cluster-a" NetBox API credentials: export NETBOX_SERVER_URL="https://netbox.example.com" export NETBOX_API_TOKEN="..." Verify VM Metadata curl -s \ -H "Authorization: Token $NETBOX_API_TOKEN" \ -H "Accept: application/json" \ "$NETBOX_SERVER_URL/api/virtualization/virtual-machines/?name=$VM_NAME" \ | jq '.results[] | { id, name, status: .status.value, cluster: .cluster.name, vcpus, memory_mb: .memory, disk_size_mb: .disk, primary_ip4: .primary_ip4.address }' Confirm: ...

Use this checklist when resizing Terraform-managed vSphere VMs after initial provisioning. The goal is to update VM state without accidentally replacing the VM, losing NetBox alignment, or skipping guest OS disk follow-up. Edit Desired State Change the VM entry in the environment VM map: locals { vms = { "app-1" = { name = "cluster-a-app-01" ipv4_address = "192.0.2.10" ipv4_netmask = tostring(var.netmask) cpu = 4 ram_gb = 32 disksize = 80 attach_data_disk = true data_disk_gb = 200 } } } Avoid manual vCenter edits for values Terraform owns. ...

When Terraform creates vSphere VMs, NetBox should not be an after-the-fact documentation step. Use NetBox as an ownership gate before vSphere VM creation, then verify Terraform removes the NetBox records when the managed VM is destroyed. Desired Order The safe order is: 1. Resolve required NetBox objects 2. Create NetBox VM record 3. Create NetBox interface record 4. Create NetBox IP address record 5. Set NetBox primary IPv4 6. Create vSphere VM The vSphere VM should depend on the NetBox primary IP relationship, not just the VM record. ...

Use this matrix to prove VM provisioning guardrails before trusting automation with real vSphere creates. The point is not to make every test pass green. The point is to prove each unsafe condition fails at the correct layer. Baseline Commands Generate a plan and plan JSON: terraform init terraform plan -out=tfplan terraform show -json tfplan > tfplan.json Run preflight: ./scripts/preflight-vm-guardrails.sh --plan-json tfplan.json Confirm clean post-apply state when a test intentionally creates a disposable VM: ...

Terraform can validate its own input, but it cannot automatically prove that the outside world is clear. Before applying a vSphere VM plan, run preflight checks against the systems that already know about names and addresses. After testing a disposable VM, verify destroy cleanup as a separate lifecycle check. Preflight protects allocation. Destroy verification protects source-of-truth hygiene. Generate Plan JSON Use the plan as the preflight input: terraform plan -out=tfplan terraform show -json tfplan > tfplan.json Then run the guardrail script: ...