XCP-ng AIops

先说清楚要解决什么

XCP-ng 集群的日常运维，真正耗时的往往不是「执行」那一步，而是前面一堆判断：哪台主机缺补丁、哪个 SR 快写满、这台 VM 为什么半夜 halt、昨晚的备份失败是 vdi-chain 还是 quiesce。传统做法是打开 Xen Orchestra 界面逐项点，或者手写 xo-cli 脚本，脚本一旦跑起来又缺少审批与留痕。

这个技能要解决的是把判断和执行放进同一个有治理的入口：读操作给出结构化结果与根因分类，写操作必须过策略引擎、预算护栏和审计日志，破坏性动作默认不可逆且需要二次确认。

它是怎么工作的

技能通过 Xen Orchestra 的 REST API（/rest/v0）工作，共 29 个 MCP 工具，分为只读的观测类（overview、vm_health_rca、sr_usage_rca、backup_failure_rca、pool_patch_ha_posture）和写入类（VM 电源与迁移、sr_rescan、快照增删回滚）。统一由 @governed_tool harness 包裹：

• 审计：所有调用写入 ~/.xcpng-aiops/ 下的本地统一日志，每条记录带风险等级。
• 成对逆操作：vm_start 会记录 vm_stop 的 undo token；vm_migrate 在迁移前抓取真实源主机并记录「迁回」；snapshot_create 从 XO 响应里取真实快照 id，并为该 id 记录反向删除。
• 预算护栏：防止循环调用（例如反复 sr rescan）造成失控开销。
• 密钥：XO token 以 Fernet + scrypt 加密存放于 ~/.xcpng-aiops/secrets.enc，磁盘上不落明文。

典型流程总是「先读后写」：先看 overview 拿到池、主机、VM 状态、接近写满的 SR 和近期备份失败；再用对应的 RCA 定位原因；确认无误后用 --dry-run 预演，去掉 --dry-run 真正执行。例如给池打补丁，流程是 pool posture 发现版本漂移 → vm list --state Running 找出需迁出的 VM → 逐台 vm migrate --dry-run 再实跑 → undo list 确认每台都有迁回 token → 打补丁重启 → 再跑一次 pool posture 验证漂移消除。

备份失败的排查链路是 backup failure-rca 先分类（vdi-chain / quiesce / transport / storage-full），再决定下一步：coalesce 未完成就等它做完，storage-full 先回收空间，transport 要去 XO UI 检查远端连通性，quiesce 失败要修 Guest Tools 而不是全局关掉静默。

适用边界

• 必须有 Xen Orchestra 5.x（启用 /rest/v0）。它是管理面入口，v0.1 不支持直连单主机的 XAPI。
• 只覆盖常见运维操作，不是全量 API 封装，覆盖清单见 docs/VERIFICATION.md。
• 不要用于非 XCP-ng 目标：Proxmox VE 请用 proxmox-aiops，NAS/存储设备、备份软件套件、Kubernetes 与网络设备都不在范围内。
• snapshot_delete 与 snapshot_revert 是高风险且不可逆，执行前会记录 BEFORE 状态，但没有 undo token；vm_reboot --force 同样不可逆。Guest Tools 缺失时不要直接升级到 --force，先做快照。
• 社区维护的开源项目，与 Vates、XCP-ng、Xen Orchestra 官方无隶属关系，源码在 github.com/AIops-tools/XCPng-AIops 以 MIT 许可公开可审计。