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.

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 (workflow orchestration) | vmware-policy (audit/policy)

uv tool install vmware-monitor

uv tool install vmware-storage

uv tool install vmware-vks

uv tool install vmware-nsx-mgmt

uv tool install vmware-nsx-security

uv tool install vmware-aria

uv tool install vmware-avi

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

• 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 reset vCenter triggered alarms

• 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

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.

• 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.

1. vmware-aiops datastore browse <ds> --pattern "*.ova"

   → confirm image present and size

2. vmware-aiops deploy ova <path> --name <date>-<owner>-<purpose> --datastore <ds>

3. vmware-aiops vm guest-exec <name> --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> --name baseline

   (only if multi-iteration testing; skip for one-shot)

5. vmware-aiops vm set-ttl <name> --minutes 480

• 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.

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

• 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.

1. Verify VM state and current host via

   vmware-monitor vm info <name>

2. Verify target host: same cluster, EVC compatible, has required networks/datastores

3. vmware-aiops vm migrate <name> --to-host <target>

   — 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

1. Verify target is reachable:

   vmware-aiops doctor

2. For self-signed certs: set

   disableSslCertValidation: true

   in config.yaml (lab environments only)

uv tool install vmware-aiops
mkdir -p ~/.vmware-aiops
vmware-aiops init  # generates config.yaml and .env templates
chmod 600 ~/.vmware-aiops/.env

All tools are automatically audited via vmware-policy. Audit logs:

vmware-audit log --last 20

Full setup guide, security details, and AI platform compatibility: see

references/setup-guide.md

@vmware_tool

• Every tool call logged to

  ~/.vmware/audit.db

  (SQLite, framework-agnostic)
• Policy rules enforced via

  ~/.vmware/rules.yaml

  (deny rules, maintenance windows, risk levels)
• Risk classification: each tool tagged as low/medium/high/critical
• View recent operations:

  vmware-audit log --last 20

• View denied operations:

  vmware-audit log --status denied