cds-ai/cdsmcp/docs/vmware-migrateops-guide.md

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.

vCenter Access

• 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.

IP And Power-State Policy (Mandatory)

• 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.

Related References

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

VMware Compute MigrateOps Defaults

• Use /home/aw/code/cds/cdsmcp/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.

Approval and Monitoring Defaults

• 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

Preflight Checklist

• Source host connected in CDC.
• Integration exists and is active in same project.
• atvm-linux-h2h powered on in vCenter.
• atvm-linux-h2h connected in same CDC project.
• Destination VM name does not already exist in vCenter.
• Destination datastore/host/network resolve in vCenter.
• source_nic discovered via SSH from source host.

CMC Preparation Rule

• 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.

Post-Migration Validation and Cleanup Pattern

• 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)

Default Behavior Contract

• Perform automatically on every VMware compute run:
• destination login validation
• operation archive
• offline-host cleanup and source/helper stale verification
• Still require explicit user confirmation before destination delete:
• always prompt
• if no confirmation, keep destination and record deletion skipped by user