SuperAPI AI Directory
Partner with us中文AI newsFavorites
All toolsAI developer platformsVMware-AIops

VMware-AIops

VMware vSphere/vCenter management: VM lifecycle, deployment, guest operations, snapshots and clusters, with confirmation gates, dry-run mode and audit logging.

Open website

About this tool

Purpose

VMware-AIops is used for AI-driven monitoring and operations of VMware vCenter/ESXi. The author is Wei Zhou (VMware by Broadcom); it is a community-driven project and is not an official VMware product. The project provides two skills: vmware-monitor (read-only, safe) and vmware-aiops (full operational operations).

Main Capabilities

  • Virtual machine lifecycle and deployment: AI-driven VM lifecycle and deployment features for 60 MCP tools, supporting deployment from OVA, batch cloning, host migration, and more.
  • Read-only investigation reports: provides five read-only report tools get_cluster_health_summary, get_cross_vcenter_attention, investigate_vm, investigate_host, investigate_datastore (requires vmware-monitor to be installed). The reports aggregate correlated server-side data and return high-signal results, and support --html output of a self-contained offline HTML snapshot (no external resources, no JavaScript).
  • Cluster management, alert management, datastore browsing, scheduled scans and notifications, and other features.
  • Plan -> Apply workflow: used for complex operations involving more than 2 steps or more than 2 VMs.

Usage

Can be installed via PyPI, or from source in offline/air-gapped environments. Supports Claude Code, Cursor, Codex, Gemini CLI, Trae, and more than 30 AI agents; the MCP server can work with any MCP-compatible agent or tool. For configuration templates, see examples/mcp-configs/.

CLI vs. MCP selection guidance: CLI is suitable for cost efficiency and small models; MCP is suitable for structured automation with large models.

Typical workflows:

  • Deploy a lab environment: browse OVAs in the datastore -> deploy a VM from OVA -> install software inside the VM -> create a baseline snapshot -> set TTL for automatic cleanup.
  • Batch clone testing: create a plan -> user review (shows affected VMs, irreversible warnings) -> apply the plan (executed sequentially, stop on failure) -> roll back on failure.
  • Migrate a VM to itsother host: check VM information via vmware-monitor -> perform migration -> verify.

Guest operations require VMware Tools running inside the VM, and a guest account must be explicitly specified (--user for CLI, username for MCP); there is no default account.

Applicable Scenarios

Suitable for managing real VMware environments (including compliance, NSX segmentation, and multi-domain scenarios) and requiring auditable AI operations. For scenarios that only need virtual machine power cycling in a single vCenter, a single-file server can be used; this project is more oriented toward complex environments that require a governance framework (see docs/compliance-ready.md).

Versions and Compatibility

pyVmomi automatically negotiates the API version during the SOAP handshake, so the same codebase can manage 7.0/8.0/9.0/9.1 environments. Version 2.0 renamed 38 of the 60 MCP tools so that each name starts with a verb (for example cluster_add_host -> add_cluster_host). For the complete old-to-new comparison table, see RELEASE_NOTES.md; the tools, parameters, safety gates, and CLI commands are unchanged. Deny rules using the old names remain effective under vmware-policy >= 1.18, and saved workflows will translate old names under vmware-pilot >= 1.13; installations before upgrading that share rules.yaml must likewise use vmware-policy >= 1.18.2.

Safety Mechanisms

  • CLI: destructive commands prompt twice and have no bypass flag; --dry-run previews all write operations, except deploy iso, deploy mark-template, vm cancel-ttl, and vm guest-download.
  • MCP: tools marked as destructive, plus migrate_vm and network/DRS write tools (23 of 43 write tools in total), require passing the confirm parameter; by default they do not write and only return an impact-scope preview. If the preview finds blocking factors (such as VMware Tools not running in the VM, target host in maintenance mode, cluster still having hosts, snapshot missing or duplicated) or cannot be read, execution is refused and recorded as a failure. delete_vm also requires echoing the previewed acknowledge_with, and is rejected when the VM has changed, is powered on, or is suspended. The remaining 20 write tools execute on first invocation. The VMWARE_READ_ONLY switch has been removed.
  • Permissions are determined by the vCenter/ESXi service account: read-only agents should use a read-only vCenter role. All calls are logged to ~/.vmware/audit.db before results are returned. Optional ~/.vmware/rules.yaml deny rules are checked before every MCP call; the default baseline denies no operations and serves as a guardrail on top of RBAC.
  • run_vm_guest_command runs the caller-provided command inside the guest with the supplied credentials; the username is required, there is no default account, and the command content is unrestricted; the guest account is an authorization boundary separate from the vCenter account, the skill does not store guest credentials, and under MCP the credentials are passed in as tool parameters (the audit line masks the password). upload_vm_guest_file can read any local file readable by the server process.

Configuration and Security Practices

  • Passwords are set via a .env file (recommended) to avoid appearing on the command line or in shell history; .env should be set to chmod 600.
  • config.yaml stores only the target hostname, port, and a reference to .env, and contains no passwords or tokens.
  • TLS is enabled by default and can be disabled only for ESXi hosts with self-signed certificates in isolated lab environments.
  • Webhooks are disabled by default; when enabled, they send only critical issues and alert/event warnings to your own URL, without going through third-party services.
  • It is recommended to use a dedicated least-privilege vCenter service account; for monitoring-only scenarios, the read-only VMware-Monitor is recommended.
  • All content from vSphere is truncated, stripped of control characters, and wrapped in boundary markers before output to prevent prompt injection.

Limitations and Caveats

Alarm reset uses AlarmManager.ClearTriggeredAlarms, which clears all triggered alarms matching the named alarm entity type (host/VM/all) and current state (red/yellow), not just the one named; cleared alarms will automatically re-trigger if the underlying condition persists. remove-host requires the host to first enter maintenance mode, after which the host is removed from the cluster and becomes a standalone host in the data center. The guest command run_vm_guest_command's basThis form returns only the exit code; to capture output, use run_vm_guest_command_with_output (MCP only). Large OVAs (>10GB) may exceed the default 120-second timeout; uploads proceed via an HTTP NFC lease.

Regarding installation commands, configuration templates, and the full tool list (references/capabilities.md), the specific command text is not provided in the materials and is not yet available.

Related tools

Browse category