Build an Ansible Control Node on vSphere

An Ansible control node can comfortably run inside a small Linux virtual machine, even when it manages a broad vSphere environment. Its role is to hold the CLI, inventories, credentials and execution environments used to run playbooks, while target hosts perform the actual configuration. Learn more about Integrating Git With Powercli For.

Setting up a virtual machine for Ansible control on vSphere works best when the guest, network and lifecycle process are designed together. This guide follows a practical path from sizing and hardening the guest through to validating access and automating repeatable builds.

Plan the Ansible control node

Start with a supported Ubuntu Server LTS or RHEL-family Linux guest. A useful baseline is two virtual CPUs, 4 GB of memory and a 40 GB disk, with four virtual CPUs and 8 GB of memory for larger inventories, execution environments or extensive logging. Thin-provisioned disks work well, but include enough capacity for collections, cached artifacts and Ansible output.

Many Australian organisations still operate on-premises vSphere clusters in Sydney and Melbourne, often supported by a managed service provider. The control node should therefore be an ordinary supported guest rather than an appliance tied to one ESXi host. Keep an administrative path to vCenter or ESXi independent of this VM so a network mistake cannot lock administrators out of the environment.

Treat inventories, playbooks and configuration as production data. Inventory and logs can contain identifiers, so review retention and access controls under the Privacy Act 1988 and the Notifiable Data Breaches scheme where they apply. Although the ASD Essential Eight is not legislation, its patching, logging and access-control controls provide a strong benchmark for Australian implementations.

Prepare the Linux guest

Deploy the guest from a trusted template or ISO and install VMware Tools for reliable clock synchronisation, guest information and clean shutdown handling. Cloud-init or vSphere Guest Customisation can apply the hostname, locale, network configuration and SSH public key during deployment, but secrets should not be embedded in an image or attached ISO.

Create a dedicated unprivileged account for automation. Add its public key to authorized_keys, disable root login over SSH and disable password authentication once key-based access has been tested. Grant only the required commands through a reviewed sudoers file rather than giving the automation account unrestricted root access.

Set the correct IANA time zone and ensure DNS, NTP and outbound routing work from the guest. These services are essential for certificate validation, host discovery and consistent timestamps across playbooks. Verify them before installing Ansible, because configuration errors discovered halfway through an automation run are harder to diagnose.

Configure vSphere networking

Place the control node on a management network or VLAN that can reach the target hosts. A DHCP reservation can provide a stable address, although a static address may suit environments with strict inventory rules. Record the assigned name and address in the source-controlled inventory instead of scattering addresses across scripts and documentation.

Apply least-privilege firewall rules to SSH and the ports required by managed systems. With NSX-T, permit control-node traffic only from approved management segments and allow the control node to reach only the services it administers. Maintain a separate administrative session while changing policies so an incorrect rule cannot interrupt the path used to correct it.

Many Australian organisations keep primary and recovery capacity across Sydney, Melbourne and other regional sites. If protected workloads are replicated between locations, verify the seed appliance and object-store connectivity; troubleshooting vSphere replication covers common failure points that can delay recovery testing.

Install and validate Ansible

Install a supported release of ansible-core using the operating system package, a virtual environment or pipx, depending on the organisation’s patching policy. Avoid an unmanaged global Python installation. Keep the control node free of unnecessary applications, and document the Ansible version so inventory and playbook behaviour can be reproduced later.

Create an ansible.cfg file and a structured inventory containing host groups, connection details and SSH key references. Store the inventory and configuration under version control, while encrypting sensitive variables with Ansible Vault and keeping vault passwords outside Git. For example, run ansible all -m ping to confirm connectivity and ansible all -m ansible.builtin.setup to collect facts.

Validate playbooks with syntax checks, linting and check mode before execution. Confirm that tasks are idempotent by running them more than once and checking for unexpected changes. Keep output available for audit purposes, but apply the same access and retention controls used for other infrastructure logs.

Automate the lifecycle and put it into action

Turn the hardened guest into a vSphere template, then use PowerCLI, cloud-init and Guest Customisation to create fresh control nodes with predictable identities and keys. Keep long-lived inventories and vaulted material in a managed repository rather than rebuilding them inside each new virtual machine. This separates operating-system provisioning from the automation configuration that depends on it.

For teams standardising microsegmentation around control-node traffic, automating NSX-T security policies shows how repeatable policy deployment can reduce manual configuration errors. The same approach supports regular reviews of which management hosts can reach which target services.

Schedule automation in UTC while displaying Australian local time, especially across daylight-saving changes in NSW, Victoria and Queensland. Account for public holidays and ordinary Australian support hours when choosing maintenance windows. Create the hardened Linux template now, clone it into a test vSphere environment, and validate the inventory against one disposable target before connecting production hosts.