Use this skill whenever the user needs to manage VMs in VMware/vSphere/ESXi — it's the entry point for all VM operations. Directly handles: power on/off, clone, snapshot, migrate, deploy from OVA or templates, run commands inside VMs, batch operations, cluster management, vCenter alarm acknowledgment, a one-glance cluster-health triage ("is anything on fire?"), and VM/host/datastore investigation drill-downs. Always use this skill for any "power on", "clone", "deploy", "migrate", "batch", "guest exec", "alarm", or VM lifecycle task, and for triage like "is anything on fire" / "what needs attention now" / "investigate this VM", when the context is explicitly VMware, vSphere, or ESXi. Do NOT use for general read-only queries (inventory/events/VM details — use vmware-monitor), NSX networking (use vmware-nsx), storage/iSCSI/vSAN (use vmware-storage), or Kubernetes cluster lifecycle (use vmware-vks). For multi-step workflows use vmware-pilot. For load balancing/AVI/AKO use vmware-avi.
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Une commande directe contourne le prompt de vérification. Examinez la source avant de l'exécuter.
La commande reste sur une seule ligne. Faites défiler horizontalement pour la vérifier avant de la copier.
Vous préférez une copie locale ? Téléchargez les fichiers actuellement disponibles dans SkillsMP.
Explorateur de fichiers
7 fichiers
Affichage de SKILL.md
SKILL.md
Instructions source · Aperçu en lecture seule
name
vmware-aiops
description
Use this skill whenever the user needs to manage VMs in VMware/vSphere/ESXi — it's the entry point for all VM operations. Directly handles: power on/off, clone, snapshot, migrate, deploy from OVA or templates, run commands inside VMs, batch operations, cluster management, vCenter alarm acknowledgment, a one-glance cluster-health triage ("is anything on fire?"), and VM/host/datastore investigation drill-downs. Always use this skill for any "power on", "clone", "deploy", "migrate", "batch", "guest exec", "alarm", or VM lifecycle task, and for triage like "is anything on fire" / "what needs attention now" / "investigate this VM", when the context is explicitly VMware, vSphere, or ESXi. Do NOT use for general read-only queries (inventory/events/VM details — use vmware-monitor), NSX networking (use vmware-nsx), storage/iSCSI/vSAN (use vmware-storage), or Kubernetes cluster lifecycle (use vmware-vks). For multi-step workflows use vmware-pilot. For load balancing/AVI/AKO use vmware-avi.
vmware-policy auto-installed as Python dependency (provides @vmware_tool decorator and audit logging). All write operations audited to ~/.vmware/audit.db. Credentials: Each vCenter/ESXi target requires a per-target password env var in ~/.vmware-aiops/.env following the pattern VMWARE_<TARGET_NAME_UPPER>_PASSWORD. Passwords are never logged or echoed. Destructive operations: All write tools require explicit parameters, pass through @vmware_tool decorator (pre-check + audit + sanitize), and CLI destructive commands require double confirmation + support --dry-run. Guest operations: Require explicit vm_name, cmd (full path), args, user parameters — no implicit or background execution. Webhooks: Disabled by default. When enabled, send only aggregated alert metadata (alarm counts, event types) to user-configured URLs. No credentials, IPs, or PII in payloads. SSL bypass: disableSslCertValidation is off by default; exists only for self-signed certs in isolated lab environments. Transitive dependencies: Only vmware-policy (audit/policy). No post-install scripts or background services.
VMware AIops
Disclaimer: This is a community-maintained open-source project and is not affiliated with, endorsed by, or sponsored by VMware, Inc. or Broadcom Inc. "VMware" and "vSphere" are trademarks of Broadcom. Source code is publicly auditable at github.com/zw008/VMware-AIops under the MIT license.
VMware family entry point — AI-powered VM lifecycle, deployment, and alarm management — 60 MCP tools.
Diagnostic investigations: Before remediating any "why is X slow / failing / down" issue, follow references/investigation-protocol.md. It enforces the four root-cause completeness criteria (falsifiability / sufficiency / necessity / mechanism) and the up-to-three-rounds deepening loop. Only invoke L3+ write tools after the four criteria are satisfied AND the user has approved a remediation plan.
Cluster Health Triage ("what's wrong right now?")
Start here when the ask is "is anything on fire?" before diving into a specific VM. This is a read-only rollup delegated to vmware-monitor, exposed here so triage-then-act stays in one conversation.
One glance --> cluster_health_summary (MCP) or vmware-aiops summary (CLI). Read top_issues first — ranked anomalies (disconnected hosts, red/yellow alarms, capacity pressure), each with a drill-down hint; the per-cluster table is context
Act on what it surfaces --> a host_down row → investigate the host; an alarm → acknowledge_vcenter_alarm / reset_vcenter_alarm; a hot VM implicated → vm_migrate or vm_reconfigure (after the investigation protocol)
Save/share a snapshot --> vmware-aiops summary --html writes an offline, timestamped HTML file (identical to vmware-monitor summary --html — same shared renderer)
If vmware-monitor is not installed --> this command/tool is unavailable (AIops delegates to it); install vmware-monitor, or use the deeper per-object read tools in that skill
Object-Centered Investigation → Act (drill-down before you change anything)
Judgment: after triage points at a problem object, drill in with one correlated read before actuating — the bundle aggregates the object with its surrounding infrastructure and recent history so you (and the operator) see the full picture, not a guess. AIops is the conversational entry point, so triage → investigate → act stays in one conversation.
Estate-wide --> cross_vcenter_attention ("what needs attention now?" across every vCenter). One vCenter configured → skip to cluster_health_summary
Drill into the flagged object (offer the level; skip the question when unambiguous):
a VM --> vm_investigation_bundle → state, host it runs on, cluster context, backing datastores, snapshots, alarms & recent changes, performance signals, correlated event timeline
a host --> host_investigation_bundle; a datastore --> datastore_investigation_bundle
Then act on the evidence --> e.g. bundle shows a wedged VM on a hot host → vm_migrate; a full datastore → vm_delete_snapshot on the sprawl the bundle surfaced. Follow the investigation protocol before any destructive action
Widen the window with hours=72; render an offline snapshot with --html (drill-down sections collapse natively, nothing uploaded)
If the object name is unknown --> the bundle returns a teaching error naming how to list objects; get the exact name and retry. If vmware-monitor is not installed --> these delegated tools are unavailable
Deploy a Lab Environment
Pre-flight (judgment, not blind sequence):
Free space: target datastore must have ≥ OVA size × 2 (delta files + thin-provision overhead). If multiple datastores qualify, prefer one with lowest current IOPS pressure (cross-check vmware-aria if available).
Name hygiene: prefix with date or owner (lab-2026-04-30-alice) so the TTL cleanup audit trail is meaningful.
TTL: always set. 480 min for a single test session, 7200 min for a week-long sandbox. Never deploy a "lab" VM without a TTL — that is how datastores fill up at 3 AM.
Snapshot timing: take the baseline after provisioning succeeds, not before — a pre-provision snapshot is just an empty checkpoint.
Decision rule: count > 10 → use linked clones (deploy linked-clone); seconds vs minutes per clone, ~100× less storage. Tradeoff: linked clones depend on source snapshot — deleting the snapshot breaks all children.
Network exhaustion: each clone gets a unique MAC from the vSphere pool; if you batch > 200, verify pool capacity in advance.
TTL: every clone must have one. Use the plan's metadata to track ownership.
Steps:
vm_create_plan with clone + reconfigure + set-ttl steps grouped per VM (atomic per clone)
Review the plan with the user — surface count, datastore, irreversible warnings
vm_apply_plan — stops on first failure (intentional, do not auto-resume)
On failure: vm_rollback_plan → reverses completed clones; manually verify rollback before retrying
Migrate VM to Another Host
Pre-flight (ALL must pass before issuing migrate):
CPU compatibility: target host CPU family must match source, OR cluster must be in EVC mode. Live migration across mismatched CPUs fails mid-flight and may leave the VM stunned.
Network parity: every portgroup the VM uses must exist on the target host's vSwitch with the same VLAN. Missing portgroup → vNICs disconnected post-migration.
Storage visibility: target host must see all of the VM's datastores; otherwise this is a Storage vMotion, not a host migration — different (slower) operation.
Affinity rules: if the VM is pinned to source by a DRS host-affinity rule, migration silently violates intent. Check cluster info first.
Hardware passthrough: VMs with PCI passthrough (GPU, USB) cannot live-migrate — schedule a cold migration window.
Steps:
Verify VM state and current host via vmware-monitor vm info <name>
Verify target host: same cluster, EVC compatible, has required networks/datastores
vmware-aiops vm migrate <name> --to-host <target> — wait for task completion, do not assume success on return
Post-check: vm info confirms new host AND power state unchanged AND vNICs connected
cluster_health_summary (delegates to vmware-monitor)
Read
Object Investigation (4)
vm_investigation_bundle, host_investigation_bundle, datastore_investigation_bundle, cross_vcenter_attention (all delegate to vmware-monitor)
Read
List envelope: the read list tools — browse_datastore, list_vcenter_alarms, vm_list_plans, vm_list_snapshots, vm_list_ttl — return {items, returned, limit, total, truncated, hint} rather than a bare array. Read the rows from items and check truncated before concluding a listing is complete; empty items with truncated: false means checked-and-none, not a failure. The write batch_* tools keep their bare list (complete by construction). Rationale, total semantics, error shape: references/capabilities.md.
Read/write split: 18 tools are read-only (per [READ] docstring marker), 42 modify state. All write tools require explicit parameters and are audit-logged. Destructive operations (vm_delete, vm_revert_snapshot, vm_delete_snapshot, vm_set_ttl (schedules an unattended auto-delete), force power-off, cluster delete/remove-host, alarm reset, remove_host_vmk, delete_drs_rule) require double confirmation at the CLI layer and support --dry-run.
Network write gating: create_dvs_portgroup, add_host_vmk, and set_vmk_service are preview/confirm-gated — confirm=False (default) returns the exact spec that would be applied without writing. remove_host_vmk is fail-closed: it refuses when the vmk is selected for a host service (management/vMotion/vSAN), lives on a non-default netstack (NSX TEPs, dedicated vMotion stacks), carries a default gateway route, or when any of that cannot be verified — pass force_unprotected=True to override the non-absolute protections. The host's only management-enabled vmk is never removable (no override). set_vmk_service is fail-closed too: it refuses both directions when the host's service map is unreadable, and refuses (no override) to untag management from the host's only management-enabled vmk — the call rides the interface it would untag.
DRS rule gating: set_drs_rule_enabled, create_drs_rule, delete_drs_rule are preview/confirm-gated and idempotent (matching state returns a no-write noop). create_drs_rule handles VM-VM affinity/anti-affinity only (≥2 distinct VMs, all cluster members); VM-Host rules are read via list_drs_rules but managed in the vSphere UI. delete_drs_rulerefuses non-VM-VM rules (they can carry licensing/compliance placement constraints) and records the full rule definition in both preview and result so a mistaken delete can be recreated from the audit trail.
Alarm reset blast radius: vSphere has no per-alarm clear API. reset_vcenter_alarm uses AlarmManager.ClearTriggeredAlarms, which clears all triggered alarms matching the named alarm's entity type (host/VM/all) and current status (red/yellow) — not just the one named. The response's scope field states exactly what was cleared. The named alarm is looked up first, so a typo fails fast without clearing anything.
CLI Quick Reference
# VM operations
vmware-aiops vm power-on <name> [--target <t>]
vmware-aiops vm power-off <name> [--force]
vmware-aiops vm create <name> --cpu 4 --memory 8192 --disk 100
vmware-aiops vm delete <name>
vmware-aiops vm clone <name> --new-name <new> [--to-host <host>] [--to-datastore <ds>] [--power-on]
vmware-aiops vm migrate <name> --to-host <host> [--to-datastore <ds>]
vmware-aiops vm snapshot-create <name> --name <snap> [--description <text>] [--memory]
vmware-aiops vm snapshot-list <name>
vmware-aiops vm snapshot-revert <name> --name <snap>
vmware-aiops vm snapshot-delete <name> --name <snap> [--remove-children] [--no-wait]
vmware-aiops vm task-status <task-id> # poll an async (--no-wait) operation by id
vmware-aiops vm set-ttl <name> --minutes 480 [--dry-run] # double confirm; daemon auto-deletes VM on expiry# Guest operations (requires VMware Tools)
vmware-aiops vm guest-exec <name> --cmd <script-path> --args "<args>" --user <username>
vmware-aiops vm guest-upload <name> --local ./script.sh --guest /tmp/script.sh --user <username>
# Deploy
vmware-aiops deploy ova <path> --name <vm> --datastore <ds>
vmware-aiops deploy linked-clone --source <vm> --snapshot <snap> --name <new>
# Cluster
vmware-aiops cluster create <name> --ha --drs
vmware-aiops cluster info <name>
vmware-aiops cluster drs-rules <name> # list DRS rules
vmware-aiops cluster drs-rule-set <name> --rule <r> --enable|--disable [--dry-run]
vmware-aiops cluster drs-rule-create <name> --rule <r> --type antiAffinity --vm <vm1> --vm <vm2> [--disabled] [--dry-run]
vmware-aiops cluster drs-rule-delete <name> --rule <r> [--dry-run] # VM-VM only; double confirm# Datastore
vmware-aiops datastore browse <ds> --pattern "*.ova"# Alarm management
vmware-aiops alarm list [--target <t>]
vmware-aiops alarm acknowledge <entity_name> <alarm_name> [--target <t>]
vmware-aiops alarm reset <entity_name> <alarm_name> [--target <t>] # double confirm; see blast radius above# Family
vmware-aiops hub status # show installed family members + install commands
Full CLI reference: see references/cli-reference.md
Troubleshooting
"VM not found" error
VM names are case-sensitive in vSphere. Use exact name from vmware-monitor inventory vms.
Guest exec returns empty output
Use vm_guest_exec_output instead of vm_guest_exec — it auto-captures stdout/stderr. Basic vm_guest_exec only returns exit code.
Deploy OVA times out
Large OVA files (>10GB) may exceed the default 120s timeout. The upload happens via HTTP NFC lease — ensure network between the machine running vmware-aiops and ESXi is stable.
Snapshot delete is slow / "still running after Ns"
Deleting an old or large snapshot consolidates its delta disk into the parent — the slowest write
operation, often several minutes. vm snapshot-delete waits up to 30 min by default; if it still
returns a "still running, NOT failed" message with a task id, the delete did not fail — poll it with
vm task-status <task-id>. Do not re-issue the delete or hand-roll polling. For very large snapshots,
prefer vm snapshot-delete <name> --name <snap> --no-wait to get the task id immediately and poll.
Plan apply fails mid-way
Run vmware-aiops plan list to see failed plan status. Ask user if they want to rollback with vm_rollback_plan. Irreversible steps (delete_vm) are skipped during rollback.
Connection refused / SSL error
Verify target is reachable: vmware-aiops doctor
For self-signed certs: set disableSslCertValidation: true in config.yaml (lab environments only)
