Cirrus Data Cloud VMware Compute MigrateOps Guide

This file is for workflow guidance only. Do not add specific run examples here.

Update Rule

After every run, update this file only when a workflow rule/checklist/default behavior changed.
Add run-specific examples and evidence to run-learnings.md only when that run produced a new learning.

Address: 192.168.0.201
Source /home/aw/code/cds/.env.credentials.local and use VCENTER_USER plus VCENTER_PASSWORD
Standard CLI path: /home/aw/.local/bin/govc
Use only this standard vCenter login for vCenter actions unless explicitly instructed otherwise.
Do not use 192.168.3.190 for vCenter actions; that machine is reserved for Cypress ATVM automation.

Before finding guest IP or attempting SSH, confirm VM power state in vCenter and power on if needed.
Treat only these as stable references:
192.168.0.201 for vCenter login only
192.168.3.190 for ATVM Cypress automation only
192.168.3.191 as default ATVM target reference
Any other VM IP must be obtained live from vCenter for that run only.
Do not carry forward ad-hoc VM IPs from previous runs in runbooks.
When the operator refers to 192.168.3.191, assume ATVM target SSH access should ignore host key mismatch by default with -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null.
When the operator refers to 192.168.3.191 for Linux SSH access, source /home/aw/code/cds/.env.credentials.local and use ATVM_TARGET_USER plus ATVM_TARGET_PASSWORD unless the operator explicitly overrides them.
When the operator refers to 192.168.3.191 for Windows guest access, source /home/aw/code/cds/.env.credentials.local and use ATVM_WINDOWS_TARGET_USER plus ATVM_WINDOWS_TARGET_PASSWORD unless the operator explicitly overrides them.
For Windows guest command execution, prefer SSH + PowerShell on the guest instead of VMware guest operations unless the operator explicitly requests otherwise.

VM lookup, datastore reporting, and FC/disk assignment:
- vm-lookup-and-assignment.md
CMC install, uninstall, and reinstall fallback:
- cmc-install-reference.md

Use templates/vmw.yaml as the starting template.
Default sequence for requested source machine:
clean CDC state for that machine
reinstall CMC on that machine
perform migration preflight and operation create
If user provides a client name, replace consistently:
config.system_name
migrateops_vmware_compute.compute.vm_name
operation name
Validate integration_name is active in target project before create.
Default access node: atvm-linux-h2h (must be powered on in vCenter and connected in CDC).
Always discover source_nic from live source host networking.

Auto-approve cutover by default.
Start monitoring immediately after operation create.
Approve as soon as final-synchronization requests input.
Skip auto-approval only if user explicitly asks for manual approval.
Patience rule:
if heartbeat/progress is advancing, keep waiting
allow longer waits for helper deployment/registration steps
intervene only for terminal failure, confirmed blocker, or prolonged no-progress

For Linux sources, use the Linux SSH credential path and the Linux install/uninstall reference.
For Windows sources, use SSH to the guest with ATVM_WINDOWS_TARGET_USER and ATVM_WINDOWS_TARGET_PASSWORD.
For both Linux and Windows, clean stale CDC project state for that machine before reinstalling CMC unless the operator explicitly wants to reuse the existing registration.
For Windows sources, check whether CMC is already installed before install.
If Windows CMC is already present, uninstall first and then reinstall using the Windows PowerShell installer command.
After reinstall on Windows, confirm the host reconnects in the CDC project as expected before creating local or remote migration sessions.
Do not treat VMware guest operations as the default Windows execution path.

Validate destination login before cleanup:
get destination guest IP from vCenter
verify SSH/login works
if guest IP empty, keep polling and do not skip validation
do not mark run complete before validation result is recorded
Before deleting destination VM:
always prompt user for explicit confirmation
never delete destination VM without that confirmation in the same run
For delete path:
resolve source VM ID and destination VM ID separately
abort if IDs match
power off destination if needed
delete destination by explicit VM ID
verify destination removed and source still exists
Always run project cleanup after terminal migration state:
archive completed operation
run global offline-host cleanup
cleanup must target source VM named in current request only
if source/helper entries still connected, force-disconnect conditions and rerun cleanup
if stale connected state persists after VM removal/power-off, wait heartbeat timeout and rerun cleanup until removed
verify helper entry from this run (migrateops-<opid>-<source-system-name>) is removed
Completion gate:
do not report run complete until archive + cleanup verification are done
always provide read-only final listing for source, destination, access node, helper:
CDC status (present or cleaned up)
vCenter status (present or cleaned up, and if present include power state + IP)