Using Ansible to Enforce VM Compliance Standards in vSphere

Virtual machine sprawl makes compliance difficult to manage. A few manually created test VMs can quickly become dozens of production workloads with inconsistent hardware versions, network connections, VMware Tools releases, snapshot histories, and security settings. Ansible provides a repeatable way to inspect and correct those differences through vCenter.

A useful compliance process begins with a written baseline. The baseline might require encrypted virtual machines, approved port groups, current VMware Tools, a defined CPU and memory range, no snapshots older than seven days, and a standard folder or tag structure. These controls can support internal governance, customer contracts, or frameworks such as the Australian Essential Eight.

The goal is not to make every VM identical. Database servers, domain controllers, VDI desktops, and application appliances have different operational needs. A good playbook separates mandatory controls from documented exceptions, allowing automation to improve consistency without disrupting legitimate designs.

For Australian organisations, this approach is especially useful across Sydney, Melbourne, Brisbane, and regional sites where infrastructure teams may support several data centres with a small operations group. A clear policy-as-code workflow also helps when workloads must remain in approved Australian facilities for sovereignty or contractual reasons.

Define A Practical VSphere Baseline

Start by translating policy into measurable attributes. Examples include VM power state, hardware compatibility level, SCSI controller type, NIC connection state, port group, firmware type, secure boot, encryption status, and VMware Tools state. Storage placement and resource pool membership can also be included where they affect performance or data handling.

Keep each requirement specific and testable. “The VM must be secure” is difficult to automate, while “all production VMs must use approved distributed port groups” produces a clear result. Store the baseline in Git so changes receive peer review and remain linked to an operational record.

Ansible should also distinguish between audit and remediation. An audit playbook can report violations without changing workloads, while a remediation playbook applies approved corrections. This separation is valuable in change-controlled environments and during after-hours maintenance windows.

Build Secure Ansible Access

The community.vmware collection supplies modules for gathering VM information, changing hardware settings, managing snapshots, and controlling power operations. The automation host needs network access to vCenter, compatible Python dependencies such as pyVmomi, and an account with narrowly scoped permissions.

Avoid placing vCenter passwords directly in playbooks or inventory files. Use Ansible Vault, an external secrets manager, or an automation platform credential store. A dedicated service account should have the minimum rights required for discovery and the specific changes approved by the organisation.

Australian businesses often operate under formal customer assurance requirements, particularly in government, healthcare, finance, and managed services. Documenting account ownership, credential rotation, and execution logs makes the automation easier to defend during audits. General website and content conditions are also available in the site disclaimer.

Discover VMs With Tags And Inventory

Reliable discovery is the foundation of compliance. Ansible can query vCenter and retrieve VM facts, but the results become more useful when workloads are organised with tags, folders, naming conventions, or custom attributes. A tag such as environment:production is generally safer than guessing an environment from a hostname.

Dynamic inventory can reduce the gap between vCenter and Ansible. Groups may represent clusters, business units, operating systems, or lifecycle states. The playbook can then apply stricter requirements to production workloads while allowing a broader configuration for development and lab VMs.

Do not rely on names alone. A VM called SQL01 may be a retired test system, while an unremarkable hostname might support a critical service. Combining tags with folder paths, datastore locations, and ownership metadata creates a stronger basis for selecting targets.

Validate Configuration Before Changing It

A compliance run should first collect facts and generate a useful report. Record the VM name, vCenter, cluster, power state, current value, expected value, and exception status. This gives operators an actionable list rather than a vague failure message.

Use Ansible check mode where module support is appropriate, but test behaviour against the exact VMware collection and vSphere version in use. Some changes have dependencies or require a powered-off VM. A virtual hardware upgrade, for example, may need an outage plan and application validation.

Validation should also catch unsafe conditions. A stale snapshot may be evidence of an active recovery plan, and changing a network port group can interrupt a workload. Add approval gates for disruptive actions, especially for systems supporting hospitals, mines, utilities, or remote Australian sites where an engineer may not be nearby.

Remediate Common VM Drift

Safe remediation commonly includes removing unauthorised snapshots, setting the correct port group, enabling NIC connection state, enforcing standard CPU and memory reservations, and applying approved VM annotations. Tags can be added automatically so ownership and compliance status remain visible in vCenter.

Some controls need a staged process. VMware Tools may require guest interaction, while encryption depends on a configured key provider and suitable vSphere permissions. Secure Boot and firmware changes can affect operating system startup, so automation should verify prerequisites and stop when they are not satisfied.

Idempotence is essential. Running the same playbook twice should produce the same compliant state without repeatedly changing or restarting a VM. Use conditional tasks, explicit values, and post-change fact gathering to confirm that the requested state was actually reached.

Handle Exceptions And Change Windows

A mature compliance system supports exceptions instead of encouraging teams to bypass automation. Store approved exceptions in Git or a service management system with an owner, reason, expiry date, and compensating control. The playbook can then report expired exceptions as compliance failures.

Schedule disruptive remediations during agreed maintenance windows. A Perth workload and a Sydney workload may have different support coverage, and daylight saving differences can complicate national operations. Express schedules in a consistent timezone and include the local maintenance window in change records.

Pair VM compliance with host lifecycle management. The ESXi update guide provides useful context for automating host updates, while VM-level controls address the configuration drift that host patching does not resolve.

Report Results And Improve Governance

A useful output has three states: compliant, remediated, and failed. Publish results to a central log, ticketing platform, or dashboard, and retain enough detail to show who ran the job, which vCenter was targeted, what changed, and whether verification succeeded.

Measure trends rather than focusing on a single run. Track recurring violations by team, cluster, template, and age. If new VMs regularly fail the same check, fix the source template or provisioning workflow instead of repeatedly correcting individual machines.

The broader VMware series can help place these practices alongside vSphere administration, automation, and infrastructure operations. Treat the playbook as a maintained engineering asset: review it after vCenter upgrades, collection changes, policy revisions, and significant platform migrations.

Compliance area	Example control	Typical Ansible action	Risk to review
Network	Approved port group and connected NIC	Reconfigure virtual NIC	Possible service interruption
Snapshots	No unauthorised or aged snapshots	Report or remove snapshots	Recovery dependency
Hardware	Approved VM compatibility level	Upgrade during a window	Guest or application impact
Security	Secure Boot, encryption, approved firmware	Validate prerequisites and remediate	Boot or key-provider dependency
Metadata	Owner, environment, and lifecycle tags	Add or correct vCenter tags	Low operational risk

Build the baseline in Git, test it against a non-production cluster, and run audit-only jobs before enabling remediation. Once the results are trusted, introduce controlled fixes through your existing change process and let Ansible provide a repeatable compliance signal across every vSphere environment.