From Tickets to Clicks: Building a Zero-License Self-Service VM Portal on vSphere with Ansible AWX

✨ Introduction — Why this guide?

If your teams still open tickets for every VM, you’re paying a latency tax on innovation. This post shows how to replace that queue with a self-service portal powered by AWX (the open-source upstream of Ansible Tower) on VMware vSphere—so users request VMs, approvers click Approve, and automation does the rest in minutes.

I/ The Hidden Bottleneck: Manual VM Provisioning in Large Organizations

In most enterprises—banks, insurers, public sector—the story hasn’t changed:

1. A project/BU submits a request with OS and VM specs (CPU, RAM, Disk, Network) plus IP/Gateway/DNS.
2. A virtualization admin clones a template in vCenter.
3. The admin logs into the guest to hand-configure IP/Gateway/DNS and final tweaks.

This collapses under continuous Test/Dev:

• Slow lead time: tickets wait; simple VMs take days.
• Error-prone: wrong Port Group, mistyped IP, inconsistent sizing/tags.
• Poor developer experience: delays create drift and shadow IT.
• Weak auditability: “who requested/approved/changed what” is murky.

Bottom line: You need a self-service portal where users log in, submit a clean request, and—after role-based approval—automation provisions a VM that exactly matches the requested specs (including static networking) in minutes, with full logs and audit trail.

II/ Your Option Playbook: VMware-Native vs. Ansible Tower vs. AWX (Open Source)

+ VMware VCF Automation (Commercial, VMware-native)
Deepest vSphere/NSX integration; leases/TTLs, quotas, chargeback/showback, day-2 ops, polished catalog UX. Great when strict policy and “one VMware way” are non-negotiable. (Licensed.)

+ Red Hat Ansible Automation Platform (Ansible Tower) (Commercial Ansible)
RBAC, approvals, schedulers, Surveys (forms), execution nodes, notifications, support. Automates vSphere via mature modules and extends to networks/databases. Solid when you want a supported, scalable Ansible control plane. (Licensed.)

+ Ansible AWX (Open source, upstream of Tower)
Delivers the essentials—Projects, Inventories, Credentials, Job Templates, Surveys, Workflow Visualizer with Approval nodes—to build a credible self-service portal on vSphere without software cost.
This guide uses AWX to implement the portal described above: users submit a form, approvers sign off, automation provisions VMs end-to-end.

III/ Build the Conveyor Belt: AWX Self-Service for vSphere

1/ Turn Playbooks into Forms & Guardrails (Workflow Job Template + Survey):

• Survey turns a playbook into a user-friendly form. Each field (CPU, RAM, VLAN, IP, Gateway, OS) becomes a runtime variable.
• Workflow Job Template lets you chain steps and insert Approval. The Visualizer Editor makes it drag-and-drop: Start → Approval → Provision → (optional notifications/CMDB updates).
• Outcome: consistent inputs, enforced approvals, clean audit, and a “portal” experience—no web app required.

2/ The vCenter Engine in 60 Seconds:

Using Ansible module community.vmware.vmware_guest can talks directly to vCenter to:

• Clone from a VM template
• Set hardware (CPU, Memory, Disk) and placement (Datacenter/Cluster/Folder/Datastore)
• Attach to the requested Port Group (VLAN)
• Apply static IP/Gateway/DNS (+ optional customization)
• Power on and wait for IP so jobs finish only when the guest is usable

AWX Surveys + Workflows + this module = your automated provisioning pipeline.

3/ Hands-On Demo – From Login to Live VM:

3.1/ Two Personas, Two Permissions

Click Users > Create 2 accounts:

• dev01 — permission Execute (launch the workflow)
• manager01 — permissions Read & Approve (review and approve dev01’s requests)

3.2/ Machine Credential (How AWX runs Ansible)

Create a Machine credential (SSH username/password or key) so AWX can execute playbooks on the Ansible control node.

3.3/ Inventory & Host (API-Driven Simplicity)

Create inventory control-node and add localhost. Provisioning is via the vCenter API, so the control node is the only target.

3.4/ Project (Where Your Code Located)

Point AWX to your playbooks (local path or Git).

• Project Base Path: where content sits
• Playbook Directory: folder with .yml files.

3.5/ Workflow Job Template & Survey (Your Self-Service Form)

Survey fields (variable names in parentheses):

• Number of CPUs (num_cpus)
• Memory (MB) (memory_mb)
• VLAN / Port Group (net_name)
• IP Address (ip_addr)
• Gateway (gw)
• Desired OS (Template name) (os)

Note: Survey Answer Variable Names must exactly match playbook variables (num_cpus, memory_mb, net_name, ip_addr, gw, os).

Note: Network VLAN: choices must match existing Port Groups on vCenter vSS or vDS.

Note: OS Template: choices must match existing template names in vCenter.

3.6/ Job Template & Playbook (The Provisioning Brain)

Create Job Template with playbook for provisioning VM

Select the inventory, project, and credentials, then choose your playbook deploy_vm_template_final.yaml with below content:

- name: Provision VM vCenter
  hosts: all
  gather_facts: false
  tasks:
    - name: Create a virtual machine from a template
      ignore_errors: no
      community.vmware.vmware_guest:
        hostname: "vcenter_hostname/IP"
        username: "vcenter_account"
        password: "vcenter_account_password"
        datacenter: "datacenter_in_vcenter"
        folder: "folder_locate_VM"
        name: Ansible-Clone-VM
        state: poweredon
        template: "{{ os }}"
        cluster: "cluster_running_VM"
        datastore: "datastore-name"
        validate_certs: false
        hardware:
           memory_mb: "{{ memory_mb }}"
           num_cpus: "{{ num_cpus }}"
        networks:
         - name: "{{ net_name }}"
           ip: "{{ ip_addr }}"
           netmask: 255.255.255.0
           gateway: "{{ gw }}"
           dns_servers:
             - <IP DNS server>
        wait_for_ip_address: true
        wait_for_ip_address_timeout: 600

Key fields at a glance

• hostname/username/password: vCenter API creds (store in AWX Credentials/Vault).
• datacenter/folder/cluster/datastore: placement.
• template: "{{ os }}": golden image picked in the Survey.
• hardware.*: sizing from the Survey.
• networks: Port Group + static IP/GW/DNS.
• wait_for_ip_address: finish only when guest is ready.
• validate_certs: false for labs; true with proper CA in prod.

Tip: make netmask and dns_servers Survey-driven too, or derive them from a VLAN profile map.

3.7/ Draw the Flow with the Visualizer (Add Approval)

Click Workflow Job Template cretead in step 3.5 > Visualizer

Click Add Node → Approval

Start → Approval (timeout 3h) → Run Job Template (provision)
If the request isn’t approved within 3 hours, it times out cleanly.

Click Add Node Execute Job Template When Request Approved (Job Template Created In Step 3.6)

3.8/ Launch & Approve (What Users See)

• dev01 launches the Workflow and fills CPU, Memory, VLAN, IP, Gateway, and OS Template.
• Workflow pauses at Approval.
• manager01 reviews and Approves.
• Job clones, customizes, powers on, waits for IP.
• Result: a VM with the exact requested config and static IP—SSH-ready for dev01 in ~2 minutes 35 seconds (typical lab timing; depends on template and datastore).

IV/ What You Win: Speed, Safety, and Scale (and Real Money)

• Speed: days → minutes via Surveys + Workflow + automated playbooks.
• Reliability: standardized builds; far fewer network/sizing mistakes.
• Governance: explicit Approval, RBAC, immutable logs for audits.
• Scale: the same small ops team supports many more requests.
• Cost control: standard sizes and tags enable showback/chargeback; add TTL/retire flows to stop VM sprawl.

Production hardening checklist

• Store secrets in AWX Credentials/Vault; never in Git.
• Validate Survey inputs (regex for IPs; choice lists for VLANs/templates).
• Integrate IPAM/DNS (Infoblox/NetBox) and ITSM/CMDB (ServiceNow).
• Add Day-2 workflows (snapshot, resize, patch, rotate keys, retire with TTL).
• Enforce naming/tags (e.g., {{ bu }}-{{ env }}-{{ app }}-{{ guid }}) for FinOps & audits.