Using VMware vRealize Automation for Customised Linux VMs

VMware vRealize Automation (vRA), now known in many releases as VMware Aria Automation, provides a controlled way to deliver Linux virtual machines from a catalogue or API. Instead of asking an administrator to clone a template and adjust settings manually, users select an approved deployment pattern and the platform applies compute, storage, network, identity, and guest customisation rules.

A useful design separates the operating system image from the deployment request. The image should contain a clean, supported Linux baseline, while the cloud template supplies values such as hostname, IP settings, disk size, environment, application role, and access groups. This approach makes provisioning repeatable without creating dozens of nearly identical templates.

Australian teams also need to account for placement, data residency, and operational time zones. A workload intended for Sydney should not silently land in a Melbourne or Perth cluster because a reservation policy was left too broad. Clear naming, regional network profiles, and approval policies help keep hybrid environments predictable.

Provisioning approach	Strengths	Limitations	Suitable use
Basic VM template clone	Fast to implement	Limited customisation and drift control	Small internal environments
vRA cloud template	Repeatable, governed, self-service	Requires design and platform administration	Standard Linux services
Cloud-init with vRA	Flexible first-boot configuration	Depends on image and guest support	Application-specific builds
vRA with Ansible	Strong post-deployment automation	Adds integration and credential management	Multi-tier services and compliance builds

Map the Provisioning Design

Begin by defining what a requester can control and what the platform must enforce. A simple Linux service might expose the hostname, environment, size, operating system version, and SSH key. The platform should retain control of datastores, resource pools, security groups, IP ranges, and approved images.

In Cloud Assembly, this design is represented through cloud accounts, regions, projects, flavour mappings, image mappings, network profiles, and cloud templates. A project links users to infrastructure and policies. Entitlements in Service Broker then determine which catalogue items those users can request.

Use separate projects or policies for development, testing, and production. A development user may deploy into a broad lab network, while a production request might require approval and a specific cluster in VMware Cloud on AWS or an on-premises vSphere site.

Prepare Images and Guest Customisation

A reliable Linux image is the foundation of successful VM provisioning. Build it with a supported distribution, VMware Tools or open-vm-tools, current security updates, a predictable disk layout, and no machine-specific hostname or SSH host keys. Ubuntu Server, Red Hat Enterprise Linux, Rocky Linux, and SUSE Linux Enterprise are common choices in VMware estates.

For modern Linux builds, cloud-init is often preferable to relying solely on legacy vSphere guest customisation. The image must include the required cloud-init modules and VMware datasource support. Test whether the distribution expects NetworkManager, netplan, wicked, or traditional configuration files before writing customisation data.

Guest customisation can set the hostname, users, SSH keys, DNS, and network details. Avoid embedding passwords or private keys in a template. Store secrets in vRA’s integrated secrets mechanism or an approved vault, and use short-lived credentials where possible.

Build the Cloud Template

A cloud template defines the desired state of the VM in YAML. A minimal design might include a machine resource, an image constraint, a flavour mapping, a network attachment, and input values for hostname or environment. Use constraints to ensure the request selects an approved image and a suitable vSphere placement.

Inputs should be validated rather than passed directly into shell commands. For example, an environment field can be limited to dev, test, or prod, while a size field maps to approved CPU and memory combinations. This prevents users from requesting arbitrary resource values or deploying to an unintended network.

Cloud-init can then perform first-boot actions such as creating application users, configuring repositories, installing monitoring agents, and applying baseline settings. For larger builds, let vRA create the VM and call Ansible for configuration management. This keeps infrastructure provisioning and software configuration in their proper layers.

Configure Networks and Australian Constraints

Network profiles should describe the actual connectivity available to each deployment zone. Include port groups, routed networks, IP ranges, DNS servers, gateways, and security requirements. A template intended for a management network should not be allowed to attach automatically to a public-facing segment.

Australian organisations frequently operate across Sydney and Melbourne facilities, with Perth sites or regional offices connected through WAN services. Define these locations as explicit cloud zones or placement constraints. For regulated workloads, document why data remains in an Australian region and check that backups, logs, and monitoring destinations follow the same rule.

Time zones can affect automation as much as geography. Configure Linux guests for the required business standard, commonly Australia/Sydney or Australia/Melbourne, rather than assuming UTC is acceptable for every application. Schedule patching and maintenance around local change windows, including the familiar late-arvo period used by many operations teams.

Apply Governance and Day-Two Operations

A VM that deploys successfully still needs ownership, monitoring, backup, and lifecycle controls. Add tags for cost centre, application, owner, environment, and data classification. These tags can drive approval policies, backup selection, reporting, and automated retirement.

Useful governance controls include:

• Approval for production or sensitive-data deployments
• Lease periods and automatic expiry for temporary VMs
• Quotas for CPU, memory, storage, and IP addresses
• Required ownership and support-group metadata

Use subscriptions or event broker workflows to trigger post-provisioning actions. Common examples include registering the VM with monitoring, adding it to a backup policy, updating CMDB records, and placing it into an Ansible inventory. Ensure each workflow is idempotent so a retry does not create duplicate records or accounts.

Test Linux Deployment Paths

Testing should cover the complete request path, including catalogue entitlement, approval, placement, guest customisation, DNS, and day-two actions. Test both a normal deployment and a deliberate failure, such as an exhausted IP pool or unavailable datastore.

A practical test matrix includes:

• New deployment in development and production projects
• Static and DHCP network configurations
• Supported Linux images across selected vSphere clusters
• Resize, snapshot, reboot, and retirement operations

Check the guest from inside the operating system as well as from vRA. Confirm the hostname, default route, DNS resolution, NTP synchronisation, SSH access, monitoring status, and package repository connectivity. A VM marked successful in the portal is not operationally complete if it cannot resolve an internal service.

Troubleshoot Failed Requests

Start with the deployment request and event timeline in vRA. The event details usually show whether the failure occurred during resource allocation, network selection, clone customisation, cloud-init, or an external workflow. Correlate that information with vCenter tasks and the guest’s cloud-init logs.

Common causes include a mismatched image mapping, an unavailable network profile, duplicate hostnames, exhausted IP addresses, unsupported cloud-init modules, and insufficient permissions for the service account. In vCenter, inspect recent tasks and alarms. In Linux, review /var/log/cloud-init.log, /var/log/cloud-init-output.log, systemd journal entries, and NetworkManager or netplan output.

Keep templates small and observable while troubleshooting. Deploy a basic VM with one network and no external integrations, then add customisation and automation in stages. This makes it easier to identify whether the fault belongs to vRA policy, vSphere infrastructure, the Linux image, or a downstream service such as DNS or Ansible.