Files
cds-ai/cdsmcp/docs/vmware-migrateops-guide.md
anthony.wen 86b1a0e4a9 Scrub tracked secrets and switch ATVM docs to local credential references
- remove hardcoded credentials, tokens, registration codes, and similar secret values from tracked ATVM and CDS MCP docs
- replace those values with references to /home/aw/code/cds/.env.credentials.local and the corresponding environment variable names
- update current operator guides to instruct sourcing .env.credentials.local before credential-dependent setup and automation workflows
- update the ATVM setup scripts to consume ATVM_TARGET_PASSWORD from the environment instead of hardcoding the Ubuntu root SSH password
- scrub the remaining tracked artifact log entry that still included the old CMC registration code
- keep the local-only credential inventory in .env.credentials.local while leaving that file untracked
2026-03-24 17:32:44 -04:00

5.0 KiB

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, source /home/aw/code/cds/.env.credentials.local and use ATVM_TARGET_USER plus ATVM_TARGET_PASSWORD unless the operator explicitly overrides them.
  • 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 Linux 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.

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