Tagging VM migrations
A migration can be recorded as a first-class, auditable VM migration record under an engagement — so a fleet programme has a durable, queryable log of which VM went from which source OS to which target, and whether the run was an initial rebuild or a maintenance re-scan.
Tagging a run
Add the tag flags to migrate:
vrtmv migrate --image web01.vmdk --target rhel9 -o out/ \
--engagement acme-2026 \
--vm-id web01 \
--migration-type initial
| Flag | Purpose |
|---|---|
--engagement <id> | External id of an existing engagement. Requires --vm-id. |
--vm-id <id> | Customer-facing VM identity (hostname, CMDB id, inventory tag). Requires --engagement. |
--migration-type <t> | initial (default) or maintenance. |
Tagging is best-effort: it records the migration after the plan is built and never fails the run. The engagement must already exist (engagements are created through the curator workspace); an unknown engagement is reported and the run still completes.
The record
Each tag upserts one vm_migration row, keyed by (engagement, vm-id, migration-type), capturing:
- the VM identifier and its depersonalized fingerprint;
- the source and destination OS (linked to curated releases where they map);
- the migration type and timestamps.
Re-running the same (engagement, vm-id, migration-type) updates the existing record rather than creating a duplicate.
initial vs maintenance
- initial — the first full cross-distro rebuild: translate, plan, and attest.
- maintenance — a re-scan of an already-migrated VM, oriented toward drift against its attested state.
The type is captured on the record so a programme can distinguish first migrations from ongoing maintenance in its reporting.