Request icon
TeamsIncomingWebhook icon
Pause icon
Loop icon
StartVm icon

Wave-Based VMware-to-AHV Migration Cutover

Orchestrate VMware-to-Nutanix AHV migration waves in Kestra. Fetch the wave plan, pause for go/no-go approval, then power on each VM one at a time.

Categories
Infrastructure

Cutting over a VMware-to-Nutanix AHV migration wave is high-stakes: replication has finished, but VMs still need to be powered on in the right order, at the right moment, after a human signs off. This blueprint orchestrates the AHV power-on step of a VMware-to-Nutanix AHV migration so a wave comes up in a controlled, observable, auditable sequence instead of a flurry of manual Prism clicks. It pulls the planned migration wave from your tooling, notifies the team, blocks on a go/no-go approval, then starts each migrated VM one at a time on Nutanix AHV.

How it works

  1. fetch_wave_plan (io.kestra.plugin.core.http.Request) issues a GET to the plan_url input and retrieves the planned migration wave for review.
  2. notify_approval (io.kestra.plugin.microsoft365.teams.TeamsIncomingWebhook) posts an Adaptive Card to Microsoft Teams telling the team a cutover is waiting for go/no-go, referencing the running execution.id.
  3. approve_cutover (io.kestra.plugin.core.flow.Pause) halts the flow for up to the approval_timeout duration until a human resumes it with a go decision.
  4. power_on_wave (io.kestra.plugin.core.flow.Loop) iterates over the vm_ext_ids array with concurrencyLimit: 1, and for each value runs start_vm (io.kestra.plugin.ee.nutanix.ahv.StartVm) to power on that VM on AHV using its vmExtId.

What you get

  • A repeatable, one-VM-at-a-time AHV power-on sequence for each migration wave.
  • A built-in human approval gate before any VM is started.
  • A Teams notification that links each pending cutover to its execution.
  • A full execution log and timeline of which VMs came up and when.

Who it's for

  • Infrastructure and virtualization teams running VMware-to-Nutanix AHV migrations.
  • Cloud and platform engineers who own cutover runbooks.
  • Migration leads who need an auditable go/no-go checkpoint per wave.

Why orchestrate this with Kestra

Prism and migration tools can move and replicate VMs, but they do not give you an event-driven, approval-gated, fully logged cutover workflow that spans your migration API, your chat tooling, and AHV. Kestra adds a declarative YAML pipeline with a native Pause approval gate, sequential power-on via Loop, retries on transient AHV API failures, and end-to-end execution lineage so every wave cutover is reproducible and reviewable. Event triggers let you wire this into upstream replication-complete signals rather than babysitting a console.

Prerequisites

  • The AHV VM extIds for the wave (post-migration) passed via vm_ext_ids.
  • A migration plan endpoint reachable from Kestra, set in plan_url.

Secrets

  • NUTANIX_HOST: Prism Central host or IP.
  • NUTANIX_TOKEN: Prism Central bearer token.
  • TEAMS_WEBHOOK_URL: Microsoft Teams incoming webhook URL for the approval notification.

Quick start

  1. Set NUTANIX_HOST, NUTANIX_TOKEN, and TEAMS_WEBHOOK_URL as secrets in your Kestra namespace.
  2. Point plan_url at your migration tool's wave endpoint.
  3. Run the flow with the vm_ext_ids for the wave.
  4. Review the Teams notification and the fetched plan, then resume the approve_cutover Pause to begin power-on.

How to extend

  • Add a retry policy to start_vm to absorb transient Prism Central API errors.
  • Append post-power-on health checks (HTTP probes, ping, app readiness) after each VM starts.
  • Replace the manual run with a trigger fired when your replication tool reports the wave is ready.
  • Send a completion summary back to Teams or another channel once the wave is fully online.
  • Plan the move off vRA and vRO alongside the hypervisor change, so your automation stays in place while the platform underneath changes. The vRA to Kestra migration guide covers the method.

Links

See How

New to Kestra?

Use blueprints to kickstart your first workflows.