Provision a VMware VM with Ansible configuration and ServiceNow registration

Replace your vRA or vRO catalog item with a single declarative Kestra flow that provisions a VMware vSphere virtual machine end to end. The blueprint clones a VM from a vCenter template, runs an Ansible playbook to configure the OS for the target environment, creates a CMDB record in ServiceNow, and posts a confirmation to Slack. Platform and infrastructure teams get one auditable execution that covers VM clone, configuration management, CMDB registration, and notification, with retries built in at the most fragile step.

How it works

1. clone_vm uses io.kestra.plugin.ee.vmware.vcenter.CloneVm to clone sourceVmName to targetVmName on the configured ESXi host and datastore, and powers it on.
2. ansible_configure uses io.kestra.plugin.ansible.cli.AnsibleCLI to render an inventory.ini pointing at the new VM and run ansible-playbook against a playbook loaded from the ANSIBLE_PLAYBOOK secret, passing the chosen environment as extra vars. A constant retry (3 attempts, 2 minutes apart) absorbs the boot and SSH warm up window.
3. servicenow_register uses io.kestra.plugin.servicenow.Post to insert a row into the cmdb_ci_vmware_instance table with the VM name, IP, environment, and the Kestra execution id for traceability.
4. notify uses io.kestra.plugin.slack.notifications.SlackIncomingWebhook to post a success message including the source template, new VM name, and address.

Common vCenter connection settings (server, username, password) are centralized in pluginDefaults for io.kestra.plugin.ee.vmware.

What you get

• One execution that captures clone, configure, register, and notify as a single audited unit of work.
• Built in retries at the Ansible step so transient SSH or cloud init delays do not fail the whole pipeline.
• A consistent CMDB record tied to the Kestra execution id, so every VM in ServiceNow has provenance.
• A Slack confirmation with the human readable details of the new host.

Who it's for

• Platform and cloud engineering teams running VMware vSphere or VCF on premises.
• Infrastructure teams migrating off vRealize Automation or vRealize Orchestrator catalog items.
• SRE and DevOps teams that need provisioning to flow into ServiceNow CMDB automatically.

Why orchestrate this with Kestra

vCenter, Ansible, ServiceNow, and Slack each have their own UI and scheduler, but none of them can drive a cross tool sequence with a single execution history. Kestra ties the four steps together with declarative YAML, per task retries (see the constant retry on ansible_configure), full task level logs and lineage, and the option to trigger this flow from an event, an API call, a webhook, or a schedule, not just from the vCenter UI. When a step fails you see exactly where and why, and you can replay from that task.

Prerequisites

• A reachable vCenter Server, with a template VM and a target ESXi host and datastore.
• An Ansible runtime available on the Kestra worker (the ansible-playbook binary on PATH).
• A ServiceNow instance with an OAuth application and a user that can write to cmdb_ci_vmware_instance.
• A Slack Incoming Webhook URL for the destination channel.

Secrets

• VMWARE_VCENTER_USERNAME: vCenter user with permission to clone VMs.
• VMWARE_VCENTER_PASSWORD: vCenter password.
• ANSIBLE_PLAYBOOK: path or content of the playbook to apply, loaded via read(secret(...)).
• SERVICENOW_DOMAIN: ServiceNow instance domain, for example mycorp.
• SERVICENOW_USER, SERVICENOW_PASSWORD: ServiceNow OAuth user credentials.
• SERVICENOW_CLIENT_ID, SERVICENOW_CLIENT_SECRET: ServiceNow OAuth client.
• SLACK_WEBHOOK: Slack Incoming Webhook URL.

Quick start

1. Add the secrets above to your Kestra namespace or tenant.
2. Edit the hardcoded values in clone_vm (hostname, datastoreName) and in pluginDefaults (server) to match your vCenter inventory.
3. Set inputs.source_vm_name to an existing template and inputs.vm_name to the new VM name.
4. Provide inputs.vm_address (the hostname or IP Ansible will use) and pick the environment.
5. Execute the flow and confirm the VM is cloned, configured, present in the CMDB, and announced in Slack.

How to extend

• Swap cmdb_ci_vmware_instance for another ServiceNow table, or chain a second Post to also open a change request.
• Add a tagging step using the vCenter plugin to label the VM with environment and owner.
• Replace the Slack notification with a ServiceNow incident if any task fails by adding an errors block.
• Drive provisioning from a webhook trigger so a self service portal can submit vm_name, source_vm_name, and environment.
• Add a teardown flow that powers off and deletes the VM and updates the CMDB record when the environment is decommissioned.

Links

• VMware plugin docs: https://kestra.io/plugins/plugin-ee-vmware
• Ansible plugin docs: https://kestra.io/plugins/plugin-ansible
• ServiceNow plugin docs: https://kestra.io/plugins/plugin-servicenow
• Slack plugin docs: https://kestra.io/plugins/plugin-notifications
• VMware orchestration with Kestra: https://kestra.io/orchestration/vmware