anthony.wen/cds-ai
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

Reorganize cdsmcp workspace into docs, templates, and artifacts

Browse Source 
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.
This commit is contained in:
anthony.wen
2026-03-21 20:57:14 -04:00
parent 274b920b40
commit 0405c09987
9 changed files with 240 additions and 135 deletions
Download Patch File Download Diff File Expand all files Collapse all files

70
cdsmcp/AGENTS.md
View File

@@ -2,55 +2,51 @@
This folder contains the VMware/vCenter + MigrateOps runbook for CDS MCP workflows.
## Files
- `esxvm.md`: index file only; points to guide and run-learnings docs.
- `esxvm-guide.md`: authoritative workflow/rules/checklists/default behavior.
- `esxvm-runs.md`: run-specific learnings, only when a run adds new information.
- `vmw.yaml`: base template for `MIGRATEOPS_VMWARE_COMPUTE` operations.
## Workspace Layout
- `README.md`
- top-level navigation
- `docs/vmware-migrateops-guide.md`
- authoritative VMware compute migration workflow
- `docs/vm-lookup-and-assignment.md`
- VM lookup, datastore reporting, and FC/disk assignment workflow
- `docs/cmc-install-reference.md`
- CMC install, uninstall, and reinstall fallback reference
- `docs/run-learnings.md`
- run-specific learnings only when a run adds new information
- `templates/vmw.yaml`
- base template for `MIGRATEOPS_VMWARE_COMPUTE` operations
- `artifacts/logs/`
- runtime log artifacts kept separate from operator guidance
## Source Of Truth
- Use `esxvm-guide.md` for how to execute runs.
- Use `vmw.yaml` as the starting operation template.
- Treat `esxvm-runs.md` as evidence/history, not baseline procedure.
- Use `docs/vmware-migrateops-guide.md` for how to execute VMware compute migration runs.
- Use `docs/vm-lookup-and-assignment.md` for VM lookup responses and FC/disk assignment requests.
- Use `docs/cmc-install-reference.md` for CMC install/uninstall commands and fallback reinstall notes.
- Use `templates/vmw.yaml` as the starting operation template.
- Treat `docs/run-learnings.md` as evidence/history, not baseline procedure.
## Required Run Pattern
1. Confirm source VM in vCenter and power state before IP/SSH actions.
2. Prepare source host (CDC cleanup + CMC reinstall/registration) and verify source is connected in CDC.
3. Validate preflight requirements from `esxvm-guide.md` (integration, access node, destination name, datastore/host/network, source NIC).
4. Create MigrateOps from `vmw.yaml` with request-specific replacements.
5. Monitor continuously and auto-approve cutover unless user requests manual approval.
3. Validate preflight requirements from `docs/vmware-migrateops-guide.md`.
4. Create MigrateOps from `templates/vmw.yaml` with request-specific replacements.
5. Monitor continuously and auto-approve cutover unless the user requests manual approval.
6. After terminal state:
- validate destination login (poll guest IP if needed),
- validate destination login,
- archive operation,
- run offline-host cleanup loop until source/helper cleanup conditions are satisfied,
- provide final read-only status listing for source/destination/access/helper across CDC and vCenter.
7. Ask user explicitly before deleting destination VM; never delete without same-run confirmation.
## VM Lookup Requirement
- Unless user explicitly asks otherwise, scope VM lookup/list responses to cluster `QACL-ATVMCypressONLY`.
- For vCenter VM lookup requests, always include datastore name and VM notes/annotation in the response.
## VM Disk And FC Assignment Requirement
- For requests to assign disks and PCI passthrough FC adapters to a VM, use the workflow in `esxvm-guide.md`.
- Always verify the VM, live ESXi host, and datastore first.
- Default expected host is `192.168.1.165`, but verify live placement before planning.
- Unless the operator explicitly specifies alternatives, default to planning these FC adapters:
- `vmhba7` (`0000:85:00.0`)
- `vmhba8` (`0000:85:00.1`)
- Unless the operator explicitly specifies alternatives, default to planning these existing datastore disks:
- `atvm-DISK_1.vmdk`
- `atvm-DISK_2.vmdk`
- The disks must be located in the same datastore as the VM under the `atvm-DISKS` directory.
- If the default or operator-specified adapters or disks are missing, do nothing and report that no assignment will be performed.
- Always provide a read-only summary of findings and planned assignment, then wait for explicit approval before any change.
## Update Rules
- Update `esxvm-guide.md` only when workflow/rules/default behavior changes.
- Update `esxvm-runs.md` only when a run reveals a new learning/failure pattern/required check.
- Keep `esxvm.md` as a lightweight index.
7. Ask the user explicitly before deleting the destination VM; never delete without same-run confirmation.
## Environment Defaults
- vCenter: `192.168.0.201`
- Cluster scope: `QACL-ATVMCypressONLY` unless user overrides.
- Cluster scope: `QACL-ATVMCypressONLY` unless user overrides
- Default CDC project: `Skidamarink`
- Default access node: `atvm-linux-h2h`
- Default ATVM target reference: `192.168.3.191`
## Update Rules
- Update `docs/vmware-migrateops-guide.md` only when migration workflow/default behavior changes.
- Update `docs/vm-lookup-and-assignment.md` only when lookup/assignment workflow behavior changes.
- Update `docs/cmc-install-reference.md` only when install or reinstall reference behavior changes.
- Update `docs/run-learnings.md` only when a run reveals a new learning/failure pattern/required check.

28
cdsmcp/README.md Normal file
View File

@@ -0,0 +1,28 @@
# CDS MCP Workspace
This folder contains the VMware/vCenter and MigrateOps runbook material used for CDS MCP workflows.
## Start Here
- VMware compute migration workflow:
- `docs/vmware-migrateops-guide.md`
- VM lookup and FC/disk assignment workflow:
- `docs/vm-lookup-and-assignment.md`
- CMC install and uninstall reference:
- `docs/cmc-install-reference.md`
- Run-specific learnings:
- `docs/run-learnings.md`
- Base operation template:
- `templates/vmw.yaml`
## Layout
- `docs/`
- operator guidance and learnings
- `templates/`
- reusable operation template inputs
- `artifacts/logs/`
- runtime log artifacts
## Update Policy
- Update workflow docs when rules, defaults, or checklists change.
- Update `docs/run-learnings.md` only when a run adds a new lasting lesson.
- Keep `templates/vmw.yaml` as the starting template for VMware compute MigrateOps operations.

81
cdsmcp/artifacts/logs/atvm-codextest-vm-03-18-2026.log Normal file
View File

@@ -0,0 +1,81 @@
ATVM Local Data Disk CDC Migration Report
Host: atvm-codextest-vm
Date: 03-18-2026
VM IP during run: 192.168.3.191
Project: Skidamarink
Guest OS: Oracle Linux Server 9.7
Summary
- Powered on the VM and reinstalled CMC for Linux.
- Used /dev/sdb as the source data disk and /dev/sdc as the destination data disk.
- Created an ext4 filesystem on /dev/sdb and mounted it at /mnt/disk1.
- Created a local migration session for /dev/sdb -> /dev/sdc.
- Wrote about 1 GiB of data to /mnt/disk1/aw.dat with fio while the session was active.
- Waited for the session to resynchronize and return to TRACKING with remaining data at 0.
- Performed cutover, then final cutover.
- Unmounted the source mount after final cutover, deleted the session, mounted the destination disk at /mnt/destination, and verified the migrated file.
Disk Layout
- Source disk: /dev/sdb
- Source filesystem: ext4
- Source mountpoint: /mnt/disk1
- Destination disk: /dev/sdc
- Destination mountpoint after completion: /mnt/destination
CMC Reinstall
- Registration code: BZHKABCODZLIOK6RTAJ4
- Endpoint: portal.gcstage.cloud.nonprod.cirrusdata.com:443
- Result: successful
Migration Session
- Local session ID: 1
- Session UUID: 6d086de2-de8f-40c9-8a1c-c22712abce28
- Description: aw local ext4 validation
- Auto resync interval after explicit update: 5s
fio Write
- Command intent: write about 1 GiB to /mnt/disk1/aw.dat
- File created: /mnt/disk1/aw.dat
- File size: 1.0G
- fio runtime: 1924 ms
- fio bandwidth: 532 MiB/s
- fio write IOPS: 532
Source File Verification
- Source path: /mnt/disk1/aw.dat
- SHA-256: b695f7743705a16ef6c346d7d3a962d3608d10af4eae12e7474e2224efc0fe47
Key Session State
- Session created successfully.
- Initial file write produced changed data on the session.
- Explicit sync completed and the session returned to TRACKING with remaining = 0.
- Session then entered cutover/cmotion successfully.
Important Session Events
- SESSION_SYNCHRONIZED at 2026-03-19T01:45:52.643383535Z
- SESSION_ENTERED_CMOTION at 2026-03-19T01:45:53.440862866Z
- SESSION_FINAL_CUTOVER_EXECUTED at 2026-03-19T01:46:08.831400665Z
- SESSION_DELETED at 2026-03-19T01:46:12.798177270Z
Post-Cutover Handling
- /mnt/disk1 unmounted before session deletion.
- Migration session deleted successfully.
- No migration sessions remained after deletion.
Destination Verification
- Destination disk mounted at /mnt/destination from /dev/sdc
- Destination file: /mnt/destination/aw.dat
- Destination SHA-256: b695f7743705a16ef6c346d7d3a962d3608d10af4eae12e7474e2224efc0fe47
Verification Result
- Source and destination SHA-256 values match exactly.
- Data verification passed.
Final Guest Disk State
- /dev/sdb present and not mounted
- /dev/sdc mounted at /mnt/destination as ext4
Notes
- The session remained in TRACKING with changed data after the fio write until an explicit auto-resync interval and sync were applied.
- Cutover succeeded first; final cutover had to wait until the session transitioned from TRACKING to STANDING_IN.

33
cdsmcp/docs/cmc-install-reference.md Normal file
View File

@@ -0,0 +1,33 @@
# CMC Install Reference
This file contains the CMC install, uninstall, and reinstall fallback reference used by the CDS MCP VMware workflow.
## Default Project Rule
- Default project: `Skidamarink`
- Default registration code: `BZHKABCODZLIOK6RTAJ4`
- Default endpoint: `portal.gcstage.cloud.nonprod.cirrusdata.com:443`
- Use a different project code only when the user explicitly requests it in that run.
## Skidamarink Install (Linux)
```bash
curl https://get.cirrusdata.cloud/install-cmc | bash -s -- -rgc BZHKABCODZLIOK6RTAJ4 -gce portal.gcstage.cloud.nonprod.cirrusdata.com:443 -pkg-mode PRE_RELEASE
```
## Skidamarink Install (Windows)
```powershell
iex "& { $(irm https://get.cirrusdata.cloud/install-cmc-win) } -rgc BZHKABCODZLIOK6RTAJ4 -gce portal.gcstage.cloud.nonprod.cirrusdata.com:443 -pkg-mode PRE_RELEASE"
```
## Uninstall (Linux)
```bash
curl https://get.cirrusdata.cloud/install-cmc | bash -s -- -uninstall
```
## Uninstall (Windows)
```powershell
iex "& { $(irm https://get.cirrusdata.cloud/install-cmc-win) } -uninstall"
```
## CMC Reinstall Fallback (RHEL 10)
- If installer-based reinstall fails due repo metadata/download errors, use cached local `mtdi-daemon` and `galaxy-migrate` RPMs, start services, enforce `galaxy_complete_endpoint`, then manually register.
- Do not continue MigrateOps create until the source host is visible as connected in CDC.

0
cdsmcp/esxvm-runs.md → cdsmcp/docs/run-learnings.md
View File

57
cdsmcp/docs/vm-lookup-and-assignment.md Normal file
View File

@@ -0,0 +1,57 @@
# VM Lookup And Assignment
This file covers vCenter VM lookup responses and the workflow for assigning existing disks and PCI passthrough FC adapters to a VM.
## Cluster Scope Rule
- Only work under cluster `QACL-ATVMCypressONLY` unless explicitly told otherwise.
## Ignore VMs
- `vCLS-bf0ec6f6-c7e2-4383-b11e-9c97cec7ed44`
- `vCLS-e5b3c60e-6a1c-46a6-8357-191fc0ab8e14`
## IP Lookup Rule
- If asked about an IP address, only check powered-on VMs.
## VM Lookup Response Rule
- Unless the user explicitly asks otherwise, return VM lookup/list results only from cluster `QACL-ATVMCypressONLY`.
- For vCenter VM lookup requests, always report:
- VM name
- datastore name
- VM notes/annotation
- include power state and IP when available
## VM Disk And FC Assignment Workflow
- When asked to assign existing disks and PCI passthrough FC adapters to a specified VM, treat the request as a two-step workflow:
- first gather and report findings
- then wait for explicit approval before making any changes
- Always log into vCenter `192.168.0.201`.
- Find the specified VM and verify the ESXi host it is currently running on.
- Default expected ESXi host is `192.168.1.165`, but always verify live placement before planning changes.
- Always identify and report the datastore where the VM is stored before planning disk attachment.
- Unless the operator explicitly specifies alternatives, default to these PCI passthrough FC adapters:
- `vmhba7` (`0000:85:00.0`)
- `vmhba8` (`0000:85:00.1`)
- Do not substitute any other PCI FC passthrough adapters if either default or operator-specified adapter cannot be found.
- Unless the operator explicitly specifies alternatives, default to these existing disks from the VM's datastore under the `atvm-DISKS` directory:
- `atvm-DISK_1.vmdk`
- `atvm-DISK_2.vmdk`
- Do not substitute any other disks if either default or operator-specified disk cannot be found.
- If the specified adapters or specified disks cannot be found, do nothing and report that nothing will be assigned.
- Before any assignment action, always provide a summary of:
- the VM found
- the ESXi host
- the datastore
- whether `vmhba7` and `vmhba8` were found and are usable
- whether `atvm-DISK_1.vmdk` and `atvm-DISK_2.vmdk` were found under `atvm-DISKS`
- exactly what would be assigned
- Never perform the assignment step until the operator explicitly approves after seeing that summary.
## Common VM Credentials
- Username: `root`
- Password: `cdsi2012`
## Status Output Format (Power-Off/Revert/Power-On)
- `VM [vm name] was poweredOn, so I powered it off` (or `already poweredOff`)
- `Snapshot rollback completed`
- `VM [vm name] powered back on successfully`
- `Current IP: <ip>`

96
cdsmcp/esxvm-guide.md → cdsmcp/docs/vmware-migrateops-guide.md
View File

@@ -1,10 +1,10 @@
# ESX / vCenter Guide
# 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 `esxvm-runs.md` only when that run produced a new learning.
- 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`
@@ -25,94 +25,14 @@ This file is for workflow guidance only. Do not add specific run examples here.
- 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.
## Cluster Scope Rule
- Only work under cluster `QACL-ATVMCypressONLY` unless explicitly told otherwise.
## Ignore VMs
- `vCLS-bf0ec6f6-c7e2-4383-b11e-9c97cec7ed44`
- `vCLS-e5b3c60e-6a1c-46a6-8357-191fc0ab8e14`
## IP Lookup Rule
- If asked about an IP address, only check powered-on VMs.
## VM Lookup Response Rule
- Unless user explicitly asks otherwise, return VM lookup/list results only from cluster `QACL-ATVMCypressONLY`.
- For vCenter VM lookup requests (for example name/contains filters), always report:
- VM name
- datastore name
- VM notes/annotation
- include power state and IP when available
## VM Disk And FC Assignment Workflow
- When asked to assign existing disks and PCI passthrough FC adapters to a specified VM, treat the request as a two-step workflow:
- first gather and report findings,
- then wait for explicit approval before making any changes.
- Always log into vCenter `192.168.0.201`.
- Find the specified VM and verify the ESXi host it is currently running on.
- Default expected ESXi host is `192.168.1.165`, but always verify the live host before planning changes.
- Always identify and report the datastore where the VM is stored before planning disk attachment.
- Unless the operator explicitly specifies alternatives, default to these PCI passthrough FC adapters:
- `vmhba7` (`0000:85:00.0`)
- `vmhba8` (`0000:85:00.1`)
- Do not substitute any other PCI FC passthrough adapters if either default or operator-specified adapter cannot be found.
- Unless the operator explicitly specifies alternatives, default to these existing disks from the VM's datastore under the `atvm-DISKS` directory:
- `atvm-DISK_1.vmdk`
- `atvm-DISK_2.vmdk`
- Do not substitute any other disks if either default or operator-specified disk cannot be found.
- If the specified adapters or specified disks cannot be found, do nothing and report that nothing will be assigned.
- Before any assignment action, always provide a summary of:
- the VM found,
- the ESXi host,
- the datastore,
- whether `vmhba7` and `vmhba8` were found and are usable,
- whether `atvm-DISK_1.vmdk` and `atvm-DISK_2.vmdk` were found under `atvm-DISKS`,
- exactly what would be assigned.
- Never perform the assignment step until the operator explicitly approves after seeing that summary.
## Common VM Credentials
- Username: `root`
- Password: `cdsi2012`
## CMC Install/Uninstall Commands
### Default Project Rule
- Default project: `Skidamarink`
- Default registration code: `BZHKABCODZLIOK6RTAJ4`
- Default endpoint: `portal.gcstage.cloud.nonprod.cirrusdata.com:443`
- Use a different project code only when user explicitly requests it in that run.
### Skidamarink Install (Linux)
```bash
curl https://get.cirrusdata.cloud/install-cmc | bash -s -- -rgc BZHKABCODZLIOK6RTAJ4 -gce portal.gcstage.cloud.nonprod.cirrusdata.com:443 -pkg-mode PRE_RELEASE
```
### Skidamarink Install (Windows)
```powershell
iex "& { $(irm https://get.cirrusdata.cloud/install-cmc-win) } -rgc BZHKABCODZLIOK6RTAJ4 -gce portal.gcstage.cloud.nonprod.cirrusdata.com:443 -pkg-mode PRE_RELEASE"
```
### Uninstall (Linux)
```bash
curl https://get.cirrusdata.cloud/install-cmc | bash -s -- -uninstall
```
### Uninstall (Windows)
```powershell
iex "& { $(irm https://get.cirrusdata.cloud/install-cmc-win) } -uninstall"
```
### CMC Reinstall Fallback (RHEL 10)
- If installer-based reinstall fails due repo metadata/download errors, use cached local `mtdi-daemon` and `galaxy-migrate` RPMs, start services, enforce `galaxy_complete_endpoint`, then manually register.
- Do not continue migrateops create until source host is visible as connected in CDC.
## Status Output Format (Power-Off/Revert/Power-On)
- `VM [vm name] was poweredOn, so I powered it off` (or `already poweredOff`)
- `Snapshot rollback completed`
- `VM [vm name] powered back on successfully`
- `Current IP: <ip>`
## 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/vmw.yaml` as the starting template.
- 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

10
cdsmcp/esxvm.md
View File

@@ -1,10 +0,0 @@
# ESX / vCenter Notes Index
This file is now an index only.
- Guide-only workflow and rules: `/home/aw/code/cds/cdsmcp/esxvm-guide.md`
- Run-specific learnings log: `/home/aw/code/cds/cdsmcp/esxvm-runs.md`
Update policy:
- After each run, update `esxvm-guide.md` only for guide/rule changes.
- After each run, update `esxvm-runs.md` only if the run produced a new learning.

0
cdsmcp/vmw.yaml → cdsmcp/templates/vmw.yaml
View File