anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
0405c09987493d36f0e757ae65c180c42c5d9734
cds-ai/cdsmcp/docs/vmware-migrateops-guide.md
anthony.wen 0405c09987 Reorganize cdsmcp workspace into docs, templates, and artifacts 
Restructure the cdsmcp folder to separate operator guidance, reusable templates, and runtime artifacts into clearer top-level areas.

Move the VMware migration guide and run learnings into docs/, move vmw.yaml into templates/, move the existing log into artifacts/logs/, replace the old index file with a README, and split the former monolithic guide into focused documents for VMware MigrateOps workflow, VM lookup and FC/disk assignment, and CMC install reference.

Update internal references so the reorganized layout remains coherent without changing the underlying operational guidance.
2026-03-21 20:57:14 -04:00

4.9 KiB
Raw Blame History

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
  • Username: administrator@qalab.cdsi.local
  • Password: CDSi101!
  • 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, assume default SSH credentials root / cdsi2012 unless the operator explicitly overrides them.

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 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
Reference in New Issue View Git Blame Copy Permalink