Automating VM deployment with Ansible and custom VM templates

Creating a virtual machine in vCenter is quick; recreating it consistently across environments is where automation earns its keep. A custom template supplies the operating system, packages and configuration an application expects, while Ansible turns that baseline into a repeatable deployment process.

The workflow combines a reviewed template, inventory describing the target hosts, and playbooks that create, configure and verify each guest. Teams use the same source-controlled process for development, disaster recovery and routine capacity growth, with an audit trail instead of scattered console actions.

This guide covers VMware vSphere deployments built with Ansible and the community.vmware collection. It covers template selection, guest customisation, credential handling and post-deployment checks for home labs and production platforms managed by Australian IT teams.

Consideration	Manual vCenter deployment	Ansible with custom templates
Source of truth	Template selection and operator actions	Versioned inventory, templates and playbooks
Guest customisation	Mostly manual after cloning	OS customisation, cloud-init or configuration management
Repeatability	Varies with the administrator	Consistent builds across environments
Auditability	Separate notes and change records	Git history, logs and task results
Best suited to	One-off labs and exploration	Repeatable service provisioning
Main trade-off	Little setup effort	Template and playbook maintenance

Create a reliable template baseline

A template should represent a known-good operating system, not a general-purpose installer. Harden the image, install required agents, apply organisational policy and test it before publishing it as a vSphere template or content library item. Packer can build the image, but the published template remains the deployment contract. The approach reflects the infrastructure focus described in Jonathan Frappier’s background.

Treat each template version as a controlled artefact. Publish a new version, update the template reference used by Ansible and avoid silently editing running production guests. Keeping templates immutable makes rollback, comparison and compliance evidence much easier.

Connect Ansible to vSphere

Install the community.vmware collection and test connectivity to the vCenter endpoint before adding guest tasks. Keep placement details in inventory and secrets in encrypted group variables rather than in the playbook. Use Ansible Vault and validate the endpoint certificate against its trusted authority.

- name: Deploy a guest from a vSphere template
  hosts: vmware
  gather_facts: false
  serial: 1
  tasks:
    - name: Clone and start the virtual machine
      community.vmware.vmware_guest:
        name: "{{ guest_name }}"
        template: "{{ template_name }}"
        datacenter: "{{ datacenter }}"
        folder: "{{ target_folder }}"
        datastore: "{{ target_datastore }}"
        networks:
          - name: "{{ target_network }}"
        state: poweredon

This minimal example clones a template and powers it on; identifiers and placement values come from inventory. Add the appropriate guest customisation specification for Windows or cloud-init settings for Linux after testing them independently. Use serial: 1 when simultaneous clones would compete for the same datastore or network prerequisites.

Describe hosts, networks and placement

Inventory should identify the vSphere environment, target folder, datastore, network and guest name for every deployment. Use groups to separate production from non-production, and keep the site mapping in files that can be reviewed with Git. Australian organisations often coordinate Sydney, Melbourne and Brisbane sites, so host groups help direct each build to the correct management plane and honour data-residency requirements.

Keep secrets separate from ordinary inventory and grant each deployment only the permissions required to clone and configure its guest. Avoid shell histories and shared spreadsheets for credentials. For teams that also manage application code, the source-control workflow shown in this Git-based development example can complement infrastructure as code.

Apply operating system customisation

Cloning supplies the disk, but guest customisation determines how the machine joins the network and identifies itself. Windows guests typically need a vSphere guest customisation specification matched to their Sysprep profile; Linux guests can use cloud-init when the image supports it. Confirm the operating system family and image generation before applying customisation.

Set local conventions explicitly rather than accepting inherited defaults. An en-AU locale, Australia/Sydney or Australia/Melbourne time zones and correct daylight-saving rules make a difference for Australian support teams, while Australia/Brisbane does not observe daylight saving. Align keyboard layout, naming and dates with the organisation’s support procedures.

Security baselines matter just as much as localisation. Australian teams can use ASD Essential Eight guidance and ACSC publications to inform patching, privileged access management and hardened images. Where a workload uses VMware Cloud on AWS, check regional availability and Australian procurement through AWS Marketplace before treating a cloud endpoint like on-premises infrastructure.

Verify each deployment

A successful API call does not guarantee a healthy virtual machine. After cloning, query the power state, hardware summary and guest network information, then confirm that VMware Tools is running and the expected address has been assigned. Fail the pipeline when these checks fail, so a broken build cannot pass unnoticed.

Use Ansible facts sparingly because the guest may not be reachable immediately after cloning. Retry information collection with bounded delays, and separate infrastructure verification from guest configuration. A configuration-management run can then install packages, apply settings and register the application deployment.

Treat repeat runs carefully: the cloning module may recognise an existing guest rather than rebuilding it. Use explicit health checks and change records to prove that the existing machine still matches the intended baseline. Capture the template identifier, task results and vCenter events with each pipeline artefact.

Run the workflow as a service

Treat the playbook, inventory and template specification as operational code. Review changes through Git, protect secrets with vault encryption, restrict vCenter permissions and schedule recurring validation to detect template drift. Keep access limited to administrators who publish images and run deployments.

A practical rhythm is to rebuild a disposable test guest from the same template, compare it with production and retire obsolete images on a defined schedule. Keep a rollback path and document who can publish a new template. This turns deployment automation into a controlled service rather than fragile scripts.

Subscribe to Virtxpert for practical infrastructure guides, then automate one non-critical virtual machine in a development vCentre using a tested template, reviewed inventory and vault-protected credentials. Promote the proven workflow to production and reuse it for every new service deployment.