Vmware Aiops

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/vmware-skills/VMware-AIops under the MIT license.

VMware family entry point — AI-powered VM lifecycle, deployment, and alarm management — 60 MCP tools.

> Start here: install vmware-aiops first, then add modules as needed. > Run vmware-aiops hub status to see which family members are installed. > Family: vmware-monitor (inventory/health), vmware-storage (iSCSI/vSAN), vmware-vks (Tanzu Kubernetes), vmware-nsx (NSX networking), vmware-nsx-security (DFW/firewall), vmware-aria (metrics/alerts/capacity), vmware-avi (AVI/ALB/AKO), vmware-harden (compliance baselines). > | [vmware-pilot](../vmware-pilot/SKILL.md) (workflow orchestration) | [vmware-policy](../vmware-policy/SKILL.md) (audit/policy)

What This Skill Does

| Category | Tools | Count | |----------|-------|:-----:| | VM Lifecycle | power on/off, create, reconfigure, clone, migrate, delete, snapshot CRUD, TTL auto-delete, clean slate | 16 | | Deployment | OVA, template, linked clone, batch clone/deploy | 8 | | Guest Ops | exec commands, upload/download files, provision | 5 | | Plan/Apply | multi-step planning with rollback | 4 | | Cluster | create, delete, HA/DRS config, add/remove hosts, DRS VM-VM rules (list/create/delete/enable-disable) | 10 | | Datastore | browse files, scan for images | 2 | | Network | dvSwitch portgroup list/create, host VMkernel list/add/remove/tag-service, DF-bit MTU-path ping | 7 | | Alarm Management | list alarms, acknowledge, reset | 3 | | Triage & Investigation (read-only, delegates to vmware-monitor) | one-glance cluster health summary, object-centered VM/host/datastore drill-down bundles, cross-vCenter "what needs attention now?" | 5 |

Quick Install

uv tool install vmware-aiops
vmware-aiops doctor
vmware-aiops hub status   # see which family members are installed

VMware Family — Install What You Need

vmware-aiops is the entry point. Add modules for additional capabilities:

| Module | Install | Adds | |--------|---------|------| | vmware-monitor | uv tool install vmware-monitor | Read-only inventory, alarms, events | | vmware-storage | uv tool install vmware-storage | iSCSI, vSAN, datastore management | | vmware-vks | uv tool install vmware-vks | Tanzu Kubernetes (vSphere 8.x+) | | vmware-nsx | uv tool install vmware-nsx-mgmt | NSX networking: segments, gateways, NAT | | vmware-nsx-security | uv tool install vmware-nsx-security | DFW microsegmentation, security groups | | vmware-aria | uv tool install vmware-aria | Aria Ops metrics, alerts, capacity | | vmware-avi | uv tool install vmware-avi | AVI load balancer, ALB, AKO, Ingress |

> Each module stays independent — small tool count keeps local models (Ollama, Qwen) accurate.

When to Use This Skill

• Power on/off, create, delete, snapshot, clone, or migrate VMs
• Deploy VMs from OVA, templates, linked clones, or batch specs
• Run commands or transfer files inside a VM (Guest Operations)
• Create/configure clusters (HA/DRS)
• Browse datastores for deployable images
• Plan and execute multi-step operations with rollback
• List, acknowledge, and clear vCenter triggered alarms (clear matches by entity type + status — see MCP Tools section)

Use companion skills for:

• Inventory, health, alarms, VM info → vmware-monitor
• iSCSI, vSAN, datastore management → vmware-storage
• Tanzu Kubernetes (Supervisor, Namespace, TKC) → vmware-vks
• Load balancing, AVI/ALB, AKO, Ingress → vmware-avi

Related Skills — Skill Routing

| User Intent | Recommended Skill | |-------------|------------------| | Read-only monitoring, zero risk | vmware-monitor (uv tool install vmware-monitor) | | Storage: iSCSI, vSAN, datastores | vmware-storage (uv tool install vmware-storage) | | VM lifecycle, deployment, guest ops | vmware-aiops ← this skill | | Tanzu Kubernetes (vSphere 8.x+) | vmware-vks (uv tool install vmware-vks) | | NSX networking: segments, gateways, NAT | vmware-nsx (uv tool install vmware-nsx-mgmt) | | NSX security: DFW rules, security groups | vmware-nsx-security (uv tool install vmware-nsx-security) | | Aria Ops: metrics, alerts, capacity | vmware-aria (uv tool install vmware-aria) | | Multi-step workflows with approval | vmware-pilot | | Compliance baselines (CIS / 等保 / PCI-DSS), drift detection, LLM remediation advisor | vmware-harden (uv tool install vmware-harden) | | Load balancer, AVI, ALB, AKO, Ingress | vmware-avi (uv tool install vmware-avi) | | Audit log query | vmware-policy (vmware-audit CLI) |

Common Workflows

> Diagnostic investigations: Before remediating any "why is X slow / failing / down" issue, follow [references/investigation-protocol.md](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.

1. 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
2. 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)
3. Save/share a snapshot --> vmware-aiops summary --html writes an offline, timestamped HTML file (identical to vmware-monitor summary --html — same shared renderer)
4. 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.

1. Estate-wide --> cross_vcenter_attention ("what needs attention now?" across every vCenter). One vCenter configured → skip to cluster_health_summary
2. 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

1. 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
2. Widen the window with hours=72; render an offline snapshot with --html (drill-down sections collapse natively, nothing uploaded)
3. 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.

Steps:

1. vmware-aiops datastore browse --pattern "*.ova" → confirm image present and size
2. vmware-aiops deploy ova --name -- --datastore
3. vmware-aiops vm guest-exec --cmd /usr/bin/python3 --args "setup.py" --user admin → if exit ≠ 0, stop, do not snapshot a half-provisioned VM
4. vmware-aiops vm snapshot-create --name baseline (only if multi-iteration testing; skip for one-shot)
5. vmware-aiops vm set-ttl --minutes 480

Batch Clone for Testing

Pre-flight:

• Source VM state: powered-off is safest. If powered-on, VMware Tools must be running and quiesce-capable, else clones may have inconsistent disk state.
• Capacity math: free_space ≥ source.size × count × 1.2 (full clone) or ≥ count × 2 GB (linked clone, delta-only).
• 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:

1. vm_create_plan with clone + reconfigure + set-ttl steps grouped per VM (atomic per clone)
2. Review the plan with the user — surface count, datastore, irreversible warnings
3. vm_apply_plan — stops on first failure (intentional, do not auto-resume)
4. 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:

1. Verify VM state and current host via vmware-monitor vm info
2. Verify target host: same cluster, EVC compatible, has required networks/datastores
3. vmware-aiops vm migrate --to-host — wait for task completion, do not assume success on return
4. Post-check: vm info confirms new host AND power state unchanged AND vNICs connected

Usage Mode

| Scenario | Recommended | Why | |----------|:-----------:|-----| | Local/small models (Ollama, Qwen) | CLI | ~2K tokens vs ~8K for MCP | | Cloud models (Claude, GPT-4o) | Either | MCP gives structured JSON I/O | | Automated pipelines | MCP | Type-safe parameters, structured output |

MCP Tools (60 — 18 read, 42 write)

| Category | Tools | R/W | |----------|-------|:---:| | VM Lifecycle (16) | vm_list_ttl, vm_list_snapshots, vm_task_status | Read | | | vm_power_on, vm_power_off, vm_create, vm_reconfigure, vm_clone, vm_migrate, vm_delete, vm_create_snapshot, vm_revert_snapshot, vm_delete_snapshot, vm_set_ttl, vm_cancel_ttl, vm_clean_slate | Write | | Deployment (8) | deploy_vm_from_ova, deploy_vm_from_template, deploy_linked_clone, attach_iso_to_vm, convert_vm_to_template, batch_clone_vms, batch_linked_clone_vms, batch_deploy_from_spec | Write | | Guest Ops (5) | vm_guest_download | Read | | | vm_guest_exec, vm_guest_exec_output, vm_guest_upload, vm_guest_provision | Write | | Plan/Apply (4) | vm_list_plans | Read | | | vm_create_plan, vm_apply_plan, vm_rollback_plan | Write | | Datastore (2) | browse_datastore, scan_datastore_images | Read | | Network (7) | list_dvs_portgroups, list_host_vmks, vmk_ping | Read | | | create_dvs_portgroup, add_host_vmk, remove_host_vmk, set_vmk_service | Write | | Cluster (10) | cluster_info, list_drs_rules | Read | | | cluster_create, cluster_delete, cluster_add_host, cluster_remove_host, cluster_configure, set_drs_rule_enabled, create_drs_rule, delete_drs_rule | Write | | Alarm Management (3) | list_vcenter_alarms | Read | | | acknowledge_vcenter_alarm, reset_vcenter_alarm | Write | | Cluster Triage (1) | 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

…

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: vmware-skills
• Source: vmware-skills/VMware-AIops
• License: MIT
• Homepage: https://skills.sh/zw008/VMware-AIops

Install and usage instructions live in the source repository linked above.