The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the VMware AIops listing page.
Author: Wei Zhou, VMware by Broadcom — wei-wz.zhou@broadcom.com This is a community-driven project by a VMware engineer, not an official VMware product. For official VMware developer tools see developer.broadcom.com.
English | 中文
AI-powered VMware vCenter/ESXi VM lifecycle and deployment tool — 60 tools.
Companion skills handle everything else:
Skill Scope Install vmware-monitor Read-only: inventory, health, alarms, events, metrics uv tool install vmware-monitorvmware-storage Datastores, iSCSI, vSAN management uv tool install vmware-storagevmware-vks Tanzu Namespaces, TKC cluster lifecycle uv tool install vmware-vksNeed read-only monitoring only? Use VMware-Monitor — zero destructive code in the codebase.
Triage → investigate → act, all in one conversation. Five opinionated read-only reports aggregate and correlate server-side and hand back a high-signal result (never raw inventory), so you can decide where to look before changing anything. Each renders a self-contained offline HTML snapshot with --html (no external assets; drill-down detail collapses in native <details>, zero JavaScript). All delegate to the vmware-monitor library using AIops's own vCenter connection.
| Question | Command | What it correlates |
|---|---|---|
| "What needs attention now?" across all vCenters | vmware-aiops attention | Every vCenter merged into one globally-ranked issue list; unreachable targets degrade gracefully |
| "Is anything on fire?" across all clusters | vmware-aiops summary | Every cluster's hosts + VM power + live CPU/mem + alarms → ranked top-N issues + per-cluster status |
| "What's happening around this VM?" | vmware-aiops investigate vm <name> | VM state + host + cluster + backing datastores + snapshots + alarms + performance + a merged event timeline |
| "What's happening around this host?" | vmware-aiops investigate host <name> | Host state + cluster + the VMs it runs + mounted datastores + alarms + performance + correlated timeline |
| "What's happening around this datastore?" | vmware-aiops investigate datastore <name> | Capacity/free + mounting hosts + VMs it backs + alarms + correlated timeline |
Via MCP these are the tools cluster_health_summary, cross_vcenter_attention, vm_investigation_bundle, host_investigation_bundle, datastore_investigation_bundle. (Requires vmware-monitor installed.)
Works with Claude Code, Cursor, Codex, Gemini CLI, Trae, and 30+ AI agents:
This project uses the modern PEP 517 build system (hatchling), so there is no
setup.py by design — that is expected, not a missing file. If you cloned the
source and hit ERROR: File "setup.py" or "setup.cfg" not found ... editable mode currently requires a setuptools-based build, your pip is older than 21.3 and
cannot do an editable (-e) install with a non-setuptools backend. Editable
mode is a developer convenience, not needed to run the tool — do one of:
For a truly air-gapped host, build the wheels on a connected machine and copy them over — the target then needs no network:
Most open-source VMware MCP servers (e.g. bright8192/esxi-mcp-server,
giuliolibrando/vmware-vsphere-mcp-server) are single-vCenter VM wrappers:
list/power/snapshot a VM, basic monitoring, a confirm=True flag. They explicitly
do not cover networking, storage, Kubernetes, ops analytics, load balancing, or
compliance — and "logging is documented" is not an audit trail.
This is one skill in an 11-package family that covers the whole estate and runs every tool through a governed harness:
| Other VMware MCP servers | This family | |
|---|---|---|
| VM lifecycle + monitoring | ✅ | ✅ |
| NSX networking (segments/gateways/NAT/routing/IPAM) | ❌ | ✅ vmware-nsx |
| NSX security (DFW/groups/IDS-IPS/traceflow) | ❌ | ✅ vmware-nsx-security |
| Storage (datastore/iSCSI/vSAN) | ❌ | ✅ vmware-storage |
| Tanzu Kubernetes (Supervisor/Namespace/TKC) | ❌ | ✅ vmware-vks |
| Aria Operations (metrics/alerts/capacity) | ❌ | ✅ vmware-aria |
| AVI / NSX ALB load balancing + AKO | ❌ | ✅ vmware-avi |
| Compliance baselines + drift (CIS/SCG/等保/PCI) | ❌ | ✅ vmware-harden |
| Governed harness (unified audit, policy engine, token budget + runaway breaker, graduated risk tiers, undo-token, prompt-injection sanitize) | ❌ | ✅ vmware-policy on every tool |
If you only ever power-cycle VMs in one vCenter, a single-file server is fine. If you run a real (regulated, NSX-segmented, multi-domain) VMware estate and need an AI operator an auditor can sign off on, that's what this family is for — see docs/compliance-ready.md.
| Category | Tools | Count |
|---|---|---|
| VM Lifecycle | power on/off, TTL auto-delete, clean slate | 6 |
| 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 | 6 |
| Datastore | browse files, scan for images | 2 |
| Network | dvSwitch portgroup list/create, host VMkernel list/add/remove, DF-bit MTU-path ping | 6 |
| Scenario | Recommended | Why |
|---|---|---|
| Local/small models (Ollama, Qwen <32B) | CLI | ~2K tokens context vs ~10K for MCP; small models struggle with many tool schemas |
| Token-sensitive workflows | CLI | SKILL.md + Bash tool = minimal overhead |
| Cloud models (Claude, GPT-4o) | Either | Both work; MCP gives structured JSON I/O |
| Automated pipelines / Agent chaining | MCP | Type-safe parameters, structured output, no shell parsing |
| Monitoring / storage / K8s | Companion skills | See vmware-monitor, vmware-storage, vmware-vks |
Rule of thumb: Use CLI for cost efficiency and small models. Use MCP for structured automation with large models.
| vSphere / VCF Version | Support | Notes |
|---|---|---|
| VCF 9.1 / vSphere 9.1 | ✅ Full | Released 2026-05-12. pyVmomi <10.0 resolves and connects via SOAP; new REST-only features (PATCH /deployment/size, IPv6-only GOSC) not yet wrapped — see VCF Python SDK for those. |
| VCF 9.0 / vSphere 9.0 | ✅ Full | pyVmomi 8.0.3+ connects against vSphere 9 SOAP API. From VCF 9, pyVmomi is also bundled inside the unified VCF Python SDK. |
| 8.0 / 8.0U1-U3 | ✅ Full | CreateSnapshot_Task deprecated → use CreateSnapshotEx_Task |
| 7.0 / 7.0U1-U3 | ✅ Full | All APIs supported |
| 6.7 | ✅ Compatible | Backward-compatible, tested |
| 6.5 | ✅ Compatible | Backward-compatible, tested |
pyVmomi auto-negotiates the API version during SOAP handshake — no manual configuration needed. The same codebase manages 7.0 / 8.0 / 9.0 / 9.1 environments seamlessly.
vmware-aiops datastore browse <ds> --pattern "*.ova"vmware-aiops deploy ova ./image.ova --name lab-vm --datastore ds1vmware-aiops vm guest-exec lab-vm --cmd /bin/bash --args "-c 'apt-get install -y nginx'" --user rootvmware-aiops vm snapshot-create lab-vm --name baselinevmware-aiops vm set-ttl lab-vm --minutes 480vm_create_plan with multiple clone + reconfigure stepsvm_apply_plan executes sequentially, stops on failurevm_rollback_plan reverses executed stepsvmware-monitor → verify power state and current hostvmware-aiops vm migrate my-vm --to-host esxi-02| Operation | Command | Confirmation | vCenter | ESXi |
|---|---|---|---|---|
| Power On | vm power-on <name> | — | ✅ | ✅ |
| Graceful Shutdown | vm power-off <name> | Double | ✅ | ✅ |
| Force Power Off | vm power-off <name> --force | Double | ✅ | ✅ |
| Reset | plan action reset via vm_create_plan (MCP; no CLI command) | — | ✅ | ✅ |
| Suspend | plan action suspend via vm_create_plan (MCP; no CLI command) | — | ✅ | ✅ |
| Create VM | vm create <name> --cpu --memory --disk | — | ✅ | ✅ |
| Delete VM | vm delete <name> | Double | ✅ | ✅ |
| Reconfigure | vm reconfigure <name> --cpu --memory | Double | ✅ | ✅ |
| Create Snapshot | vm snapshot-create <name> --name <snap> | — | ✅ | ✅ |
| List Snapshots | vm snapshot-list <name> | — | ✅ | ✅ |
| Revert Snapshot | vm snapshot-revert <name> --name <snap> | Double | ✅ | ✅ |
| Delete Snapshot | vm snapshot-delete <name> --name <snap> [--no-wait] | Double | ✅ | ✅ |
| Task Status | vm task-status <task-id> | — | ✅ | ✅ |
| Clone VM | vm clone <name> --new-name <new> | Double | ✅ | ✅ |
| vMotion | vm migrate <name> --to-host <host> | Double | ✅ | ❌ |
| Set TTL | vm set-ttl <name> --minutes <n> | Double | ✅ | ✅ |
| Cancel TTL | vm cancel-ttl <name> | — | ✅ | ✅ |
| List TTLs | vm list-ttl | — | ✅ | ✅ |
| Clean Slate | vm clean-slate <name> [--snapshot baseline] | Double | ✅ | ✅ |
| Guest Exec | vm guest-exec <name> --cmd /bin/bash --args "..." --user <account> | Double | ✅ | ✅ |
| Guest Exec (with output) | MCP only: vm_guest_exec_output (username required) — no CLI command | — | ✅ | ✅ |
| Guest Upload | vm guest-upload <name> --local f.sh --guest /tmp/f.sh --user <account> | Double | ✅ | ✅ |
| Guest Download | vm guest-download <name> --guest /var/log/syslog --local ./syslog --user <account> | — | ✅ | ✅ |
Guest Operations require VMware Tools running inside the guest OS, and the guest account is always named explicitly —
--useron the CLI,usernameover MCP. There is no default, so no call runs as root without choosing root.vm_guest_exec_output(MCP only; the CLI has no equivalent) auto-detects Linux/Windows shell and captures stdout/stderr.
For complex operations involving 2+ steps or 2+ VMs, use the plan/apply workflow instead of executing individually:
| Step | What Happens |
|---|---|
| 1. Create Plan | AI calls vm_create_plan — validates actions, checks targets in vSphere, generates plan with rollback info |
| 2. Review | AI shows plan to user: steps, affected VMs, irreversible warnings |
| 3. Apply | vm_apply_plan executes sequentially; stops on failure |
| 4. Rollback (if failed) | Asks user whether to rollback, then vm_rollback_plan reverses executed steps (irreversible steps skipped) |
Plans stored in ~/.vmware-aiops/plans/, auto-deleted on success, auto-cleaned after 24h.
| Operation | Command | Speed | vCenter | ESXi |
|---|---|---|---|---|
| Deploy from OVA | deploy ova <path> --name <vm> | Minutes | ✅ | ✅ |
| Deploy from Template | deploy template <tmpl> --name <vm> | Minutes | ✅ | ✅ |
| Linked Clone | deploy linked-clone --source <vm> --snapshot <snap> --name <new> | Seconds | ✅ | ✅ |
| Attach ISO | deploy iso <vm> --iso "[ds] path/to.iso" | Instant | ✅ | ✅ |
| Convert to Template | deploy mark-template <vm> | Instant | ✅ | ✅ |
| Batch Clone | deploy batch-clone --source <vm> --count <n> | Minutes | ✅ | ✅ |
| Batch Deploy (YAML) | deploy batch spec.yaml | Auto | ✅ | ✅ |
| Operation | Command | Confirmation | vCenter | ESXi |
|---|---|---|---|---|
| Cluster Info | cluster info <name> | — | ✅ | ❌ |
| Create Cluster | cluster create <name> [--ha] [--drs] | — | ✅ | ❌ |
| Delete Cluster | cluster delete <name> | Double | ✅ | ❌ |
| Add Host | cluster add-host <cluster> --host <host> | Double | ✅ | ❌ |
| Remove Host | cluster remove-host <cluster> --host <host> | Double | ✅ | ❌ |
| Configure HA/DRS | cluster configure <name> [--ha/--no-ha] [--drs/--no-drs] | Double | ✅ | ❌ |
remove-hostrequires the host to be in maintenance mode first; the host is moved out of the cluster into the datacenter's host folder as a standalone host.
| Operation | Command | Confirmation | vCenter | ESXi |
|---|---|---|---|---|
| List Triggered Alarms | alarm list [--target <t>] | — | ✅ | ❌ |
| Acknowledge Alarm | alarm acknowledge <entity> <alarm> | — | ✅ | ❌ |
| Clear (Reset) Alarms | alarm reset <entity> <alarm> | Double | ✅ | ❌ |
Blast radius: vSphere has no per-alarm clear API.
alarm resetusesAlarmManager.ClearTriggeredAlarms, which clears all triggered alarms matching the named alarm's entity type (host/VM/all) and current status (red/yellow) — not just the named one. The named alarm is looked up first (typos fail fast), and the output'sscopefield reports exactly what was cleared. Cleared alarms re-trigger automatically if their underlying condition persists.
| Feature | vCenter | ESXi | Details |
|---|---|---|---|
| Browse Files | ✅ | ✅ | List files/folders in any datastore path |
| Scan Images | ✅ | ✅ | Discover ISO, OVA, OVF, VMDK across all datastores |
| Feature | Details |
|---|---|
| Daemon | APScheduler-based, configurable interval (default 15 min) |
| Multi-target Scan | Sequentially scan all configured vCenter/ESXi targets |
| Scan Content | Each cycle: triggered alarms, vCenter events from the last lookback_hours, and new lines in the ESXi host logs hostd, vmkernel, vpxa |
| Host Logs | Read incrementally: each line is reported once per daemon run (a restarted daemon re-reads each log's last 500 lines once). A rotated log, or more than 500 new lines between cycles, adds an info row saying which lines were not scanned. Reading host logs needs the Global.Diagnostics privilege, which vCenter's Read-Only role does not include; a log that cannot be read becomes an info row with the reason, never a silent "all clear" |
| Log Analysis | Host-log lines matching error, fail, critical, panic, lost access, cannot, timeout, refused, corrupt — lines with critical/panic/corrupt are critical, the rest warning |
| Structured Log | JSONL output to ~/.vmware-aiops/scan.log — every issue, info rows included |
| Webhook | Slack, Discord, or any HTTP endpoint. Receives every critical issue and every alarm/event warning; host-log warnings go to the scan log only, and info rows are never sent |
| Cycle Summary | One line per cycle in the daemon's log output: findings (and how many went to the webhook), unreadable host logs, logs with unscanned lines, failed passes. If any pass failed or a target could not be reached it reads Scan INCOMPLETE, never "all clear" |
| Daemon Management | daemon start/stop/status, PID file, graceful shutdown |
| Feature | Details |
|---|---|
| Dry-Run Mode (CLI only) | --dry-run prints the exact API call without executing, on every CLI write except deploy iso, deploy mark-template, vm cancel-ttl and vm guest-download |
| Plan → Confirm → Execute → Log | CLI workflow: show current state, confirm changes, execute, audit log |
| Double Confirmation (CLI only) | Destructive and deploy CLI commands (vm power-off, delete, reconfigure, snapshot-revert/delete, clone, migrate, set-ttl, clean-slate, guest-exec, guest-upload; deploy ova, template, linked-clone, batch, batch-clone, mark-template; cluster delete, add-host, remove-host, configure, drs-rule-set/create/delete; alarm reset) require 2 sequential prompts and take no bypass flag |
| No confirmation on the MCP path | The 43 write tools an agent sees over MCP act on the first call — no confirmed= handshake, no approval tier, no read-only switch. What decides whether a write lands is the privilege of the vCenter account, and what records it is the audit trail. See What protects you |
| Rejection Logging | Declined CLI confirmations are recorded in the audit trail |
| Audit Trail | All operations logged to ~/.vmware-aiops/audit.log (JSONL) with before/after state |
| Input Validation | VM name, CPU (1-128), memory (128-1048576 MB), disk (1-65536 GB) validated |
| Password Protection | .env file loading with permission check; never in shell history |
| SSL Self-signed Support | verify_ssl: false — only for ESXi with self-signed certs in isolated labs; production should use CA-signed certificates |
| Prompt Injection Protection | vSphere event messages and host logs are truncated, stripped of control characters, and wrapped in boundary markers before output |
| Webhook Data Scope | Disabled by default. When configured, the daemon posts to your URL only: every critical issue (alarms, events, ESXi log lines matching critical/panic/corrupt, targets it could not connect to) and every alarm/event warning — host-log warnings stay in the scan log, and info rows are never sent. Each issue carries its entity name and message: sanitized alarm, event, or ESXi log text, or the connection error, which can include host names, IP addresses, and user names. No credentials from the skill's config or .env are sent |
| Task Waiting | All async operations wait for completion and report result |
| State Validation | Pre-operation checks (VM exists, power state correct) |
| Capability | vCenter | ESXi Standalone |
|---|---|---|
| vMotion migration | ✅ | ❌ |
| Cross-host clone | ✅ | ❌ |
| Cluster management | ✅ | ❌ |
| All VM lifecycle ops | ✅ | ✅ |
| OVA/Template/Linked Clone deploy | ✅ | ✅ |
| Datastore browsing & image scan | ✅ | ✅ |
| Snapshots | ✅ | ✅ |
| Guest operations | ✅ | ✅ |
Inventory, alarms, events, sensors, host services, and scanning are now in vmware-monitor.
The table above lists two different surfaces and it is worth being blunt about which protections apply to which, because getting this wrong is worse than having no protection at all — a guardrail you believe in is one you stop compensating for.
On the CLI, a destructive command asks twice and takes no bypass flag, and
--dry-run previews every write except deploy iso, deploy mark-template,
vm cancel-ttl and vm guest-download. That defends a mistyped command typed by a
human. It does not defend against an agent, which satisfies both prompts with
yes |.
Over MCP, there is no confirmation step at all. All 43 write tools —
vm_delete, cluster_delete, vm_guest_exec among them — act on the first
call. Seven host-networking and DRS tools take a confirm argument that
defaults to a no-write preview, but that is a preview switch, not an approval
gate: one more call is all it takes. This is deliberate. A confirmed=
handshake was considered in July 2026 and cut, along with the earlier
VMWARE_READ_ONLY switch, because neither was a real boundary — the switch was
enforced on the MCP path only and any agent with a shell walked around it via
the CLI, and a handshake is a speed-bump a model that intends to act steps over.
What actually decides whether a write lands is the vCenter/ESXi service
account. Give the skill an account with the privileges the work needs and no
more; vCenter refuses the rest itself, on every surface, with no way around it
from inside this skill. To run an agent read-only, give it a read-only vCenter
role — one decision, enforced where it is made. Every call is then recorded in
~/.vmware/audit.db before the caller sees a result, which is how you find out
what happened. Optional deny rules in ~/.vmware/rules.yaml, checked before
every MCP call, can refuse operations — for example, writes to targets labelled
environment: production. The shipped baseline denies nothing, and the rules
run inside the same process: a guardrail on top of RBAC, not a replacement.
vm_guest_exec is the one to think hardest about. It runs a caller-supplied
command inside the guest OS with the credentials handed to it — its username
is required (no default account); nothing bounds what the command may be. The guest account is
a separate authorization boundary from the vCenter one — a read-only vCenter
role does not constrain what this tool does inside a VM. The skill stores no
guest credentials: over MCP they are tool arguments the agent sees (the audit row
redacts the password). Pass a least-privilege guest account, and do not hand the
agent guest credentials it does not need. vm_guest_upload reads any local file
the server process can read.
The full inventory of which tools are gated and which are not is in references/capabilities.md, where the numbers are checked against the live tool registry by the test suite rather than maintained by hand.
VM names are case-sensitive in vSphere. Use exact name from vmware-monitor inventory vms.
Use vm_guest_exec_output instead of vm_guest_exec — it auto-captures stdout/stderr. Basic vm_guest_exec only returns exit code.
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.
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.
vmware-aiops doctorverify_ssl: false in config.yaml (lab environments only)| Platform | Status | Config File | AI Model |
|---|---|---|---|
| Claude Code | ✅ Native Skill | skills/vmware-aiops/SKILL.md | Anthropic Claude |
| Gemini CLI | ✅ Context file + MCP | skills/vmware-aiops/SKILL.md | Google Gemini |
| OpenAI Codex CLI | ✅ Skill + AGENTS.md | skills/vmware-aiops/SKILL.md | OpenAI GPT |
| Aider | ✅ Conventions | skills/vmware-aiops/SKILL.md | Any (cloud + local) |
| Continue CLI | ✅ Rules | skills/vmware-aiops/SKILL.md | Any (cloud + local) |
| Trae IDE | ✅ Rules | skills/vmware-aiops/SKILL.md | Claude/DeepSeek/GPT-4o/Doubao |
| Kimi Code CLI | ✅ Skill | skills/vmware-aiops/SKILL.md | Moonshot Kimi |
| MCP Server | ✅ MCP Protocol | vmware_aiops/mcp_server/ | Any MCP client |
| Python CLI | ✅ Standalone | N/A | N/A |
| Feature | Claude Code | Gemini CLI | Codex CLI | Aider | Continue | Trae IDE | Kimi CLI |
|---|---|---|---|---|---|---|---|
| Cloud AI | Anthropic | OpenAI | Any | Any | Multi | Moonshot | |
| Local models | — | — | — | Ollama | Ollama | — | — |
| Skill system | SKILL.md | Context file | SKILL.md | — | Rules | Rules | SKILL.md |
| MCP support | Native | Native | Via Skills | Third-party | Native | — | — |
| Free tier | — | 60 req/min | — | Self-hosted | Self-hosted | — | — |
The vmware-aiops MCP server works with any MCP-compatible agent or tool. Ready-to-use configuration templates are in examples/mcp-configs/.
| Agent / Tool | Local Model Support | Config Template | Integration Guide |
|---|---|---|---|
| Xiaoguai (小怪) | ✅ Self-hosted, any LLM | MCP setup | Guide |
| Goose | ✅ Ollama, LM Studio | goose.json | Guide |
| LocalCowork | ✅ Fully offline | localcowork.json | Guide |
| mcp-agent | ✅ Ollama, vLLM | mcp-agent.yaml | Guide |
| VS Code Copilot | — | vscode-copilot.json | Guide |
| Cursor | — | cursor.json | Guide |
| Continue | ✅ Ollama | continue.yaml | Guide |
| Claude Code | — | claude-code.json | — |
Xiaoguai (小怪) — a self-hostable, audit-first agent platform (Rust, single binary + embedded SQLite) from the same maintainer. It runs the vmware-aiops MCP server as one of its toolboxes; being both an MCP consumer and an MCP server, its HMAC-chained audit log and human-on-the-loop approval gates line up with this skill's own audit + confirm design. See its MCP integration guide.
Fully local operation (no cloud API required):
All platforms share the same Python backend.
Set passwords via .env file (recommended):
Security note: Prefer
.envfile over command-lineexportto avoid passwords appearing in shell history. The.envfile should havechmod 600(owner-only read/write).
Password environment variable naming convention:
ps)~/.vmware-aiops/.env with chmod 600config.yaml — credentials are loaded from .env automaticallyconfig.yaml stores target hostnames, ports, and a reference to the .env file. It does not contain passwords or tokens. All secrets are stored exclusively in .envinfo rows are never sent. Payloads carry the full issue text (entity names, alarm names, event messages, ESXi log excerpts, connection errors), which can include host names, IP addresses, and user names; they carry no credentials from your config or .envChoose one (or more) of the following:
Method 1: Skills.sh or ClawHub (recommended)
Either installer places the skill in Claude Code's skills directory for you:
Method 2: Manual skill install
For tool access (not just skill context), also register the MCP server:
Restart Claude Code, then:
Submit to Official Marketplace
This plugin can also be submitted to the Anthropic official plugin directory for public discovery.
For tool access (not just context), register the MCP server in ~/.gemini/settings.json:
Then start Gemini CLI:
Then start Codex CLI:
Configure ~/.continue/config.yaml for local model:
Then:
Copy the rules file to your project's .trae/rules/ directory:
Trae IDE's Builder Mode reads .trae/rules/ Markdown files at startup.
Note: You can also install Claude Code extension in Trae IDE and use
.claude/skills/format directly.
The MCP server exposes VMware operations as tools via the Model Context Protocol. Works with any MCP-compatible client (Claude Desktop, Cursor, etc.).
After uv tool install vmware-aiops, start the MCP server with one command (v1.5.15+):
Claude Desktop config (claude_desktop_config.json):
Behind a corporate TLS proxy? uvx may fail with
invalid peer certificate: UnknownIssuer. Use the recommendedvmware-aiops mcpform above (no network needed), or setUV_NATIVE_TLS=true.
Already installed? Re-run the install command for your channel to get the latest version:
| Install Channel | Update Command |
|---|---|
| ClawHub | clawhub install @zw008/vmware-aiops |
| Skills.sh | npx skills add vmware-skills/VMware-AIops |
| Git clone | cd VMware-AIops && git pull origin main && uv pip install --no-sources -e . (without --no-sources, uv looks for a sibling ../VMware-Monitor checkout) |
| uv | uv tool install vmware-aiops --force |
Check your current version: vmware-aiops --version
For users in China who prefer domestic cloud APIs or have limited access to overseas services.
Cost-effective, strong coding capability.
Persistent config ~/.aider.conf.yml:
Alibaba Cloud's coding model, free tier available.
Or via OpenAI-compatible endpoint:
Configure ~/.continue/config.yaml:
For fully offline operation — no cloud API, no internet, full privacy.
Aider + Ollama + local Qwen/DeepSeek is ideal for air-gapped environments.
| Model | Command | Size | Note |
|---|---|---|---|
| Qwen 2.5 Coder 32B | ollama pull qwen2.5-coder:32b | ~20GB | Best local coding model |
| Qwen 2.5 Coder 7B | ollama pull qwen2.5-coder:7b | ~4.5GB | Low-memory option |
| DeepSeek Coder V2 | ollama pull deepseek-coder-v2 | ~8.9GB | Strong reasoning |
| CodeLlama 34B | ollama pull codellama:34b | ~19GB | Meta coding model |
Hardware: 32B → ~20GB VRAM (or 32GB RAM for CPU). 7B → 8GB RAM.
Persistent config ~/.aider.conf.yml:
Tip: Local models are fully offline — perfect for air-gapped environments or strict data compliance.
See config.example.yaml for all options.
| Section | Key | Default | Description |
|---|---|---|---|
| targets | name | — | Friendly name |
| targets | host | — | vCenter/ESXi hostname or IP |
| targets | type | vcenter | vcenter or esxi |
| targets | port | 443 | Connection port |
| targets | verify_ssl | true | Verify the target's TLS certificate (set false only for self-signed lab hosts) |
| scanner | interval_minutes | 15 | Scan frequency |
| scanner | severity_threshold | warning | Min severity: critical/warning/info |
| scanner | lookback_hours | 1 | How far back to scan |
| scanner | log_types | — | Not read by any code — the daemon always reads the hostd, vmkernel and vpxa host logs. Setting it changes nothing |
| notify | log_file | ~/.vmware-aiops/scan.log | JSONL log output |
| notify | webhook_url | — | Webhook endpoint (Slack, Discord, etc.) |
Built on pyVmomi (vSphere Web Services API / SOAP).
| API Object | Usage |
|---|---|
vim.VirtualMachine | VM lifecycle, snapshots, clone, migrate |
vim.HostSystem | ESXi host info, sensors, services |
vim.Datastore | Storage capacity, type, accessibility |
vim.host.DatastoreBrowser | File browsing, image discovery (ISO/OVA/VMDK) |
vim.OvfManager | OVA import and deployment |
vim.ClusterComputeResource | Cluster, DRS, HA |
vim.Network | Network listing |
vim.alarm.AlarmManager | Active alarm monitoring |
vim.event.EventManager | Event/log queries |
| Skill | Scope | Tools | Install |
|---|---|---|---|
| vmware-aiops | VM lifecycle, deployment, guest ops, cluster, datastore browse, triage | 49 | uv tool install vmware-aiops |
| vmware-monitor | Read-only monitoring, alarms, events, investigation bundles | 27 | uv tool install vmware-monitor |
| vmware-storage | Datastores, iSCSI, vSAN | 11 | uv tool install vmware-storage |
| vmware-vks | Tanzu Namespaces, TKC cluster lifecycle | 20 | uv tool install vmware-vks |
| vmware-nsx | NSX networking: segments, gateways, NAT, routing, IPAM | 33 | uv tool install vmware-nsx-mgmt |
| vmware-nsx-security | DFW policies/rules, security groups, Traceflow, IDS/IPS | 21 | uv tool install vmware-nsx-security |
| vmware-aria | Aria Operations metrics, alerts, capacity, anomalies | 28 | uv tool install vmware-aria |
| vmware-avi | AVI (NSX ALB) load balancing, AKO Kubernetes ops | 28 | uv tool install vmware-avi |
| vmware-harden | Compliance baselines (CIS / vSphere SCG / 等保 / PCI-DSS), drift detection | 6 | uv tool install vmware-harden |
If you encounter any errors or issues, please send the error message, logs, or screenshots to zhouwei008@gmail.com. Contributions are welcome — feel free to join us in maintaining and improving this project!
MIT