Draining a Proxmox VE node before maintenance means moving every running virtual machine off it without losing uptime, and doing that by hand is slow and error prone. This blueprint orchestrates a controlled, approval-gated node drain: it lists the cluster VMs so the scope is visible, notifies the team on Slack, waits for an operator to confirm, then live-migrates each VM to a target node one at a time. The result is a repeatable, auditable maintenance procedure for Proxmox clusters that no manual runbook or raw API script can match.
How it works
list_cluster_vms (io.kestra.plugin.proxmox.cluster.ListResources with typeFilter: vm) queries the cluster and returns the current VM resources so the operator can confirm the drain scope.
notify_approval (io.kestra.plugin.slack.notifications.SlackIncomingWebhook) posts a message that a drain of the source node is paused and waiting for review, including the execution id.
confirm_drain (io.kestra.plugin.core.flow.Pause) halts the flow for up to approval_timeout (default PT1H) until an operator approves.
migrate_vms (io.kestra.plugin.core.flow.Loop over inputs.vm_names with concurrencyLimit: 1) iterates the VMs, and the inner migrate task (io.kestra.plugin.proxmox.vm.Migrate) live-migrates each one to target_node, waiting for completion before the next.
What you get
- A visible, confirmable drain scope before any VM moves.
- A human approval gate with a Slack notification and a configurable timeout.
- Sequential, one-at-a-time live migration to avoid saturating the migration network.
- A full execution record of which VMs moved, when, and to where.
Who it's for
- Platform and infrastructure engineers running Proxmox VE clusters.
- Homelab and on-prem virtualization admins automating maintenance windows.
- SREs who need an auditable, repeatable node-drain procedure.
Why orchestrate this with Kestra
Proxmox has no native scheduler for multi-step, approval-gated workflows. Kestra adds an event-driven approval gate (Pause), automatic retries on transient API or migration errors, full execution lineage across the list, notify, and migrate steps, and a declarative YAML definition you can version and review. It coordinates Proxmox and Slack in one flow, something the Proxmox UI and cron cannot do on their own.
Prerequisites
A Proxmox VE cluster with shared storage or migration networking that permits live migration between the source and target nodes.
Secrets
PROXMOX_HOST: Proxmox VE host or IP (no scheme, no port).
PROXMOX_NODE: Cluster node name used to reach the API (for example, pve1).
PROXMOX_USERNAME: PAM or PVE user in the form user@realm (for example, root@pam).
PROXMOX_PASSWORD: Password for ticket-based authentication.
SLACK_WEBHOOK_URL: Slack incoming webhook URL for the approval notification.
Quick start
- Add the five secrets above to your Kestra namespace.
- Run the flow, providing
source_node, target_node, and the vm_names to migrate.
- Approve the Pause when prompted to start the migrations; each VM moves to the target node in turn.
How to extend
- Trigger the flow automatically on a maintenance-window schedule or from an external event.
- Add a post-drain task to put the source node into Proxmox maintenance mode or shut it down.
- Send a completion notification back to Slack summarizing the migrated VMs.
- Add a reverse flow to re-balance VMs back after maintenance finishes.
Links