Configuration runsNEW
Apply configuration workflows to existing VMs with idempotent building blocks, a dry run and a results grid.
What a configuration workflow is
Configuration workflows live on the Configuration tab of Deployments and run on VMs that already exist. They use the same stages, tasks and steps as provisioning workflows, but cannot contain Proxmox actions. Example starts from a sample with building blocks and a check.
Building blocks
Building blocks are ready-made, idempotent steps for Windows guests. Each one reads the current state, changes only what differs, and reports ok (already as wanted) or changed.
| Block | Ensures |
|---|---|
| Ensure file | A file exists with exactly this content, or does not exist |
| Ensure folder | A folder exists or does not exist |
| Ensure registry value | A registry value is set (the key is created if missing) or removed |
| Ensure service | A Windows service's state and/or startup type |
| Ensure Windows feature | A Windows feature or optional feature is installed or removed |
| IPv6 on adapters | The IPv6 binding is enabled or disabled on matching adapters |
| Ensure certificate | A PEM certificate is in a LocalMachine store (matched by thumbprint) |
| Ensure firewall rule | A Windows Defender Firewall rule exists with these settings, or is removed |
Plain scripts count as changed unless their output contains a line VERLOCX_RESULT=ok.
Start a run
- 1Save the workflow, then click Run.
- 2Pick VMs from the current project (filter by name).
- 3Optionally turn on Check mode (dry run).
- 4Click Run (or Check) on the selected VMs.
- Running needs vm.remote.exec.arbitrary in the VMs' project.
- Up to 5 VMs run in parallel; steps run in order on each VM.
- VMs that are still provisioning can't be selected.
Check mode
- Building blocks report what they would change, without changing anything.
- Scripts, reboots and identity steps are skipped. Waits still run.
Results
| Result | Meaning |
|---|---|
| ok | Already as wanted; nothing changed |
| changed | Something was changed (in check mode: would be changed) |
| skipped | Not run: condition not met, Windows-only block on Linux, Proxmox step, check mode, or an earlier step failed |
| failed | The step failed; later steps on that VM are skipped unless the step continues on error |
The Runs tab shows each run as a grid of VMs by steps. Click a cell for its message and output.
Run again, cancel and lock
- After a dry run, Run for real applies it to the same VMs. Other options: Run again, Check again (dry run), and Retry the failed VMs. Reruns use the workflow's current version.
- Cancel stops every VM after its current step. The creator of a run, or someone with org.settings, can cancel it.
- Lock VMs while running (a workflow setting): while the run is on a VM, its page shows the run and the portal refuses power, delete, migrate, resources, snapshot and remote-command actions. Not applied in check mode.
- Each VM's run is recorded in its Activity with a summary of changed, ok, skipped and failed steps.
Features on this page
- Configuration runsNEW
- Idempotent building blocksNEW
- Check modeNEW
- Runs gridNEW
- Run again and retry failedNEW
- Lock VMs while runningNEW
More in AutomationAll topics
Deployment workflowsDefine what a new VM goes through, as stages, tasks and steps, and pick a workflow per template.Workflow actionsThe action catalog, variables, conditions, timeouts and error handling for workflow steps.SnapshotsPoint-in-time rollback: create, restore and delete, shown as a tree with the current state.