Skip to main content
Glama
vmware-knight

vmware-knight

VMware Knight

VMware Knight is an MCP-powered VMware operations toolkit for managing vCenter Server and standalone ESXi hosts through AI-assisted and command-line workflows.

It is designed for environments where operators need to work across multiple VMware targets without constantly remembering long FQDNs, IP addresses, or editing configuration files by hand.

Two VMware Knight features are especially important:

  • Friendly target tags — assign a simple alias such as lab-vcenter, prod-vcenter, or esxi-lab-01 to each VMware target and use that alias directly from Claude, Codex, the MCP server, or the CLI.

  • Interactive management wizard — add, edit, remove, tag, test, and configure VMware targets through a guided terminal interface.

VMware Knight also includes VMware lifecycle, deployment, guest operations, cluster management, datastore browsing, alarm operations, investigation workflows, scheduled scanning, plan/apply workflows, and an MCP server for AI-assisted operations.

VMware Knight is a community project and is not an official VMware product.

Platforms: macOS, Linux and Windows 10/11.

  • macOS users: follow the macOS user guide. Its PATH commands (Steps 3 and 5) are required.

  • Windows users: follow the Windows user guide in Option C — Windows. Its PATH commands for uv and Git (Steps 3 and 6) are required; the install fails without them. For Codex, also see docs/windows-codex.md.


About the Author

Ehsan Emad

Technology Lead | Principal Solutions Architect | Strategic Advisory | Enterprise Networking | Cybersecurity | Data Center | Agentic AI Enthusiast | MBA | CCDE #20210029 | 4× CCIE #28551 | CISSP | 2× NSE 7 | OpenShift Certified | Cisco Champion | Cisco Fire Jumper Elite

Ehsan Emad is a technology leader and principal solutions architect with extensive experience across enterprise networking, cybersecurity, data center architecture, infrastructure automation, and technical advisory.

He is the creator of VMware Knight, Cisco Knight Multi-Device MCP, Networking With Ehsan, and the TechLoungeCast podcast.

VMware Knight was created to make VMware infrastructure easier to operate through modern AI and MCP workflows while keeping target selection explicit, understandable, and manageable across environments containing multiple vCenter Servers and standalone ESXi hosts.


1. Friendly Target Tags

Managing several vCenter Servers and standalone ESXi hosts can become difficult when every operation depends on remembering IP addresses, FQDNs, or long infrastructure names.

VMware Knight adds an optional friendly tag/alias to every VMware target.

Instead of asking an AI assistant to operate against:

vc.networkingwithehsan.local

you can assign:

lab-vcenter

and then simply ask:

Using VMware Knight, list all VMs on lab-vcenter.

The same idea works for standalone ESXi hosts:

esxi-lab-01
esxi-lab-02
esxi-edge-01

Related MCP server: vcf-mcp-sddc-vc

How target resolution works

A configured VMware target can be referenced by:

  1. Friendly tag

  2. Configured target name

  3. Hostname or IP address

Example:

targets:
  - name: vcenter
    tag: lab-vcenter
    host: vc.networkingwithehsan.local
    type: vcenter
    username: administrator@vsphere.local
    port: 443
    verify_ssl: false

All of the following resolve to the same target:

lab-vcenter
vcenter
vc.networkingwithehsan.local

The friendly tag is normally the easiest identifier to use with Claude or Codex.

Example prompts

Show me the VMs on lab-vcenter.
Check cluster health on prod-vcenter.
List the VMs running on esxi-lab-01.
Show active alarms on dr-vcenter.

Tag safety

VMware Knight validates identifiers to prevent ambiguous target selection.

A tag cannot conflict with the name, hostname/IP, or tag of another configured target.

Target matching is case-insensitive, so these refer to the same configured identifier:

lab-vcenter
LAB-VCENTER
Lab-vCenter

Tags are optional. Existing target names and hostname/IP references remain valid.

For multi-vCenter and multi-ESXi environments, descriptive tags are recommended.


2. Interactive Management Wizard

VMware Knight includes a guided terminal wizard so you do not need to manually edit the VMware target YAML configuration for normal day-to-day management.

Start it with:

vmware-knight wizard

The wizard displays:

VMware Knight Management Wizard

1. List VMware targets
2. Add VMware target
3. Edit VMware target
4. Remove VMware target
5. Set/Change target tag
6. Test connections
7. Configure MCP clients
8. Exit

2.1 List VMware targets

Choose:

1. List VMware targets

The wizard displays the configured targets with information such as:

  • target name

  • friendly tag

  • target type

  • hostname or IP address

  • username

  • port

This makes it easy to confirm the exact identifiers available to the MCP server.


2.2 Add a VMware target

Choose:

2. Add VMware target

The wizard guides you through adding either:

  • a vCenter Server

  • a standalone ESXi host

You are prompted for the target information, including:

  • target name

  • friendly tag/alias

  • hostname or IP address

  • target type

  • username

  • HTTPS port

  • TLS certificate verification preference

  • password

The configuration is validated before it is accepted.

Example:

Target name: vcenter
Friendly tag/alias: lab-vcenter
vCenter/ESXi host: vc.networkingwithehsan.local

Target type:
1. vCenter
2. ESXi

Select target type: 1
Username: administrator@vsphere.local
Port: 443
Verify TLS certificate? No
Password: ********

After enrollment, the target can be referenced by the friendly tag:

lab-vcenter

2.3 Edit a VMware target

Choose:

3. Edit VMware target

The wizard shows the configured targets and asks which one you want to modify.

You can update:

  • name

  • tag

  • hostname/IP

  • vCenter or ESXi target type

  • username

  • port

  • TLS verification

  • password

If you rename a target, VMware Knight migrates the stored credential reference to the new target name.

The configuration is validated before the change is accepted.


2.4 Remove a VMware target

Choose:

4. Remove VMware target

The wizard asks you to select the target and confirm removal.

Removing a target removes:

  • the target from VMware Knight configuration

  • its stored password entry

The wizard requires confirmation before completing the removal.


2.5 Set or change a target tag

Choose:

5. Set/Change target tag

This option provides a fast way to change only the friendly alias without editing the rest of the target configuration.

Example:

vcenter -> lab-vcenter

or:

esxi-01 -> esxi-lab-01

The new tag is validated against the identifiers of all other targets before it is saved.


2.6 Test VMware connections

Choose:

6. Test connections

VMware Knight runs its connection and environment checks against the configured targets.

Use this after:

  • adding a new vCenter

  • adding an ESXi host

  • changing a password

  • changing a hostname/IP

  • modifying TLS settings

  • troubleshooting MCP connectivity

You can also run the diagnostic command directly:

vmware-knight doctor

2.7 Configure MCP clients

Choose:

7. Configure MCP clients

VMware Knight currently focuses its wizard-driven MCP configuration on:

  1. Claude Desktop

  2. OpenAI Codex

The wizard asks for the VMware Knight executable path and writes or updates the selected MCP client configuration.

The default executable location is typically:

~/.local/bin/vmware-knight                        # macOS / Linux
%USERPROFILE%\.local\bin\vmware-knight.exe        # Windows

Both options work on Windows: the wizard uses the Windows config locations, adds .exe to the path, and passes your home folder to the server (see Claude Desktop on Windows).

The generated MCP server name is:

vmware-knight

3. Installation

macOS user guide

macOS user guide — installation. Use this on a Mac that has never run VMware Knight. Run the commands in Terminal, one step at a time, and don't move on until each check passes. No administrator rights are needed, except for the Apple installer in Step 1.

Required on macOS: the PATH commands in Steps 3 and 5. You must run them so Terminal can find uv and vmware-knight. Programs installed into ~/.local/bin are not found until that folder is on your PATH. This is especially common when uv came from Homebrew, which does not add ~/.local/bin for you. That causes zsh: command not found: vmware-knight.

Step 1 — Install Git. A new Mac has no Git until Apple's Command Line Tools are installed. VMware Knight is installed straight from GitHub, so uv needs Git. Check first:

git --version

If it prints a version, go to Step 2. If a window asks you to install the command line developer tools, click Install and wait for it to finish. If nothing appears, start the installer yourself, then run git --version again:

xcode-select --install

Step 2 — Install uv. uv downloads a suitable Python automatically, so you don't need to install Python separately:

curl -LsSf https://astral.sh/uv/install.sh | sh

If you use Homebrew, brew install uv also works.

Step 3 — Add ~/.local/bin to PATH (required). You must run this command. It makes the current Terminal window see programs in ~/.local/bin, where the uv installer and VMware Knight put their commands:

export PATH="$HOME/.local/bin:$PATH"

Then check both tools. Both commands must print a version:

uv --version
git --version

Step 4 — Install VMware Knight.

uv tool install git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

To install a specific release instead of the latest code, add the tag, for example ...vmware-knight-mcp.git@v1.12.10.

Step 5 — Keep VMware Knight on PATH (required). You must run both commands. uv tool update-shell adds ~/.local/bin to your shell profile (~/.zshrc) so every new Terminal window finds vmware-knight. The export line applies it to this window too:

uv tool update-shell
export PATH="$HOME/.local/bin:$PATH"

Step 6 — Check the install.

which vmware-knight
vmware-knight --help

which should print a path like:

/Users/USERNAME/.local/bin/vmware-knight

Step 7 — Run the wizard to add your targets and tags, test the connections, and connect Claude Desktop or Codex (option 7):

vmware-knight wizard

The wizard saves your targets in ~/.vmware-knight/ and writes the full path of VMware Knight into your MCP client's config, so Claude Desktop and Codex find it without relying on PATH. Fully quit and reopen the client after option 7, then start a new chat.

On Linux, the steps are the same, except for Step 1: install Git with your package manager, for example sudo apt install git or sudo dnf install git.


Option A — Clone from GitHub

This is the recommended installation method. On a new Mac, follow the macOS user guide first. It covers installing uv and Git, and the required PATH steps.

git clone https://github.com/CyberKnightLabs/vmware-knight-mcp.git
cd vmware-knight-mcp

Install VMware Knight with uv:

uv tool install .

You can also install directly from GitHub without cloning:

uv tool install git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

Or with pip:

pip install git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

Verify the CLI installation:

vmware-knight --help

A successful installation provides these executables:

vmware-knight
vmware-knight-mcp

vmware-knight-mcp is a stdio MCP server entry point. It is normally started by an MCP client and may appear to wait silently if launched directly from a terminal. Use vmware-knight --help to verify the installation.


Option C — Windows

Windows user guide — installation. VMware Knight runs natively on Windows 10 and 11. Run these commands in PowerShell (no administrator rights needed), one step at a time, and don't move on until each check passes.

Required on Windows: the PATH commands in Steps 3 and 6. You must run them so PowerShell can find uv, Git and vmware-knight. Do not skip them, even if you opened a new window.

Why: a PowerShell window that is already open does not see programs installed after it started. This includes a new tab in the same Windows Terminal, which inherits the old PATH. That is what causes errors like uv : The term 'uv' is not recognized or Git executable not found. Step 3 below fixes it without closing anything.

Step 1 — Install uv. uv downloads a suitable Python automatically, so you don't need to install Python separately.

powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"

Step 2 — Install Git. VMware Knight is installed straight from GitHub, so uv needs Git. If winget asks you to accept its source agreement, answer Y.

winget install --id Git.Git -e --source winget

If winget is not available (some older Windows 10 installs), install Git from git-scm.com/download/win and keep the default "Git from the command line" option.

Step 3 — Add uv and Git to PATH (required). You must run this command. It reads the PATH that the two installers just saved, so the current window can find uv and git:

$env:Path = [Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [Environment]::GetEnvironmentVariable("Path", "User")

Step 4 — Check both tools. Both commands must print a version:

uv --version
git --version

If git --version still says not recognized, check that Git is on disk:

Test-Path "C:\Program Files\Git\cmd\git.exe"

If that prints True, Git is installed but its installer did not add it to PATH. You must add it permanently for your user, then repeat Steps 3 and 4:

$userPath = [string][Environment]::GetEnvironmentVariable("Path", "User")
[Environment]::SetEnvironmentVariable("Path", ($userPath.TrimEnd(";") + ";C:\Program Files\Git\cmd").TrimStart(";"), "User")

If it prints False, Git did not install: run Step 2 again, or use the installer from git-scm.com.

Step 5 — Install VMware Knight.

uv tool install git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

To install a specific release instead of the latest code, add the tag, for example ...vmware-knight-mcp.git@v1.12.10.

Step 6 — Add VMware Knight to PATH (required). You must run both commands. uv tool update-shell adds %USERPROFILE%\.local\bin to your PATH. Step 3's command makes the current window see it:

uv tool update-shell
$env:Path = [Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [Environment]::GetEnvironmentVariable("Path", "User")

Step 7 — Check the install.

where.exe vmware-knight
vmware-knight --help

where.exe should print a path like:

C:\Users\USERNAME\.local\bin\vmware-knight.exe

Then run the wizard to add your targets, exactly as on macOS:

vmware-knight wizard

Windows-specific notes:

Topic

Windows

Config folder

%USERPROFILE%\.vmware-knight\ (config.yaml and .env)

Executable

%USERPROFILE%\.local\bin\vmware-knight.exe

Codex config

%USERPROFILE%\.codex\config.toml: use the wizard, or the Windows installer script

Claude Desktop config

%APPDATA%\Claude\claude_desktop_config.json (Microsoft Store installs: under %LOCALAPPDATA%\Packages\Claude_*): use the wizard; see Claude Desktop on Windows

.env permissions

vmware-knight doctor reports the .env permission check as unknown on NTFS. This is expected, not a failure.

Find the executable

where.exe vmware-knight (instead of which)


Option B — Development Installation

Clone the repository:

git clone https://github.com/CyberKnightLabs/vmware-knight-mcp.git
cd vmware-knight-mcp

Create the project environment:

uv sync

Run VMware Knight directly from the source tree:

uv run vmware-knight --help

Start the management wizard:

uv run vmware-knight wizard

Start the MCP server:

uv run vmware-knight mcp

4. First-Time Setup

After installing VMware Knight, start the interactive management wizard:

vmware-knight wizard

The wizard can:

1. List VMware targets
2. Add VMware target
3. Edit VMware target
4. Remove VMware target
5. Set/Change target tag
6. Test connections
7. Configure MCP clients
8. Exit

A recommended first-time sequence is:

1. Add your vCenter or standalone ESXi target.
2. Assign a friendly tag such as lab-vcenter or production-vcenter.
3. Repeat for any additional VMware targets.
4. Run Test connections.
5. Configure your MCP client.
6. Start a fresh MCP client session.
7. Ask the AI client to use VMware Knight against one of your friendly tags.

Example environment:

Name            Tag              Type       Host
--------------  ---------------  ---------  -------------------------------
vcenter         lab-vcenter      vcenter    vc.example.local
esxi-01         esxi-lab-01      esxi       10.10.10.51
esxi-02         esxi-lab-02      esxi       10.10.10.52

After setup, the AI assistant can use the friendly tag directly:

Using VMware Knight, show me all VMs on lab-vcenter.

Configure Codex

VMware Knight can install its MCP configuration directly into Codex.

Windows users: the wizard (vmware-knight wizard → 7 → 2) and the command below both work on Windows. Use where.exe vmware-knight instead of which, and pass the .exe path, for example --path "$env:USERPROFILE\.local\bin\vmware-knight.exe". There is also a standalone installer script that finds the executable for you; see docs/windows-codex.md.

First locate the installed VMware Knight executable:

which vmware-knight

Typical uv installations expose it through:

~/.local/bin/vmware-knight

Install VMware Knight into Codex:

vmware-knight mcp-config install \
  --agent codex \
  --path ~/.local/bin/vmware-knight \
  --yes

VMware Knight resolves the real executable path and writes the MCP entry into:

~/.codex/config.toml

The resulting Codex configuration is similar to:

[mcp_servers.vmware-knight]
command = "/Users/USERNAME/.local/share/uv/tools/vmware-knight/bin/vmware-knight"
args = ["mcp"]
enabled = true
startup_timeout_sec = 120

After installation, start a fresh Codex session so the MCP configuration is loaded.

If the Codex CLI is available, verify the server with:

codex mcp list
codex mcp get vmware-knight

On macOS installations where Codex is bundled inside the ChatGPT application but is not on your shell PATH, you can use:

/Applications/ChatGPT.app/Contents/Resources/codex mcp list

and:

/Applications/ChatGPT.app/Contents/Resources/codex mcp get vmware-knight

A healthy configuration should report:

vmware-knight
  enabled: true
  transport: stdio
  args: mcp

Then test the live MCP connection from a fresh Codex session with a request such as:

Use the VMware Knight MCP tool cluster_health_summary against target lab-vcenter with top_n=2.

A successful Codex session should show a tool call similar to:

Called vmware-knight.cluster_health_summary(...)

This confirms Codex is using VMware Knight through MCP rather than reading local files.


5. Configuration Files

VMware Knight stores its configuration under:

~/.vmware-knight/                     # macOS / Linux
%USERPROFILE%\.vmware-knight\         # Windows

Primary files include:

~/.vmware-knight/config.yaml
~/.vmware-knight/.env

The main configuration can also be overridden with:

VMWARE_KNIGHT_CONFIG

Example:

VMWARE_KNIGHT_CONFIG=/path/to/config.yaml vmware-knight doctor

On Windows (PowerShell):

$env:VMWARE_KNIGHT_CONFIG = "C:\path\to\config.yaml"; vmware-knight doctor

Example target configuration

targets:
  - name: vcenter
    tag: lab-vcenter
    host: vc.networkingwithehsan.local
    type: vcenter
    username: administrator@vsphere.local
    port: 443
    verify_ssl: false

  - name: esxi-01
    tag: esxi-lab-01
    host: 10.10.10.51
    type: esxi
    username: root
    port: 443
    verify_ssl: false

For normal operation, use the wizard instead of manually editing this file.


6. MCP Client Setup

Claude Desktop

VMware Knight can configure Claude Desktop automatically through the management wizard.

Start the wizard from any terminal after VMware Knight is installed:

vmware-knight wizard

Then select:

7. Configure MCP clients
1. Claude Desktop

When prompted for the VMware Knight executable path, the default is typically:

~/.local/bin/vmware-knight

Press Enter to accept the default path, then confirm the installation with Y.

VMware Knight resolves the real executable path automatically and writes the MCP configuration to:

~/Library/Application Support/Claude/claude_desktop_config.json     # macOS
%APPDATA%\Claude\claude_desktop_config.json                         # Windows

A typical generated entry looks like:

{
  "mcpServers": {
    "vmware-knight": {
      "command": "/Users/USERNAME/.local/share/uv/tools/vmware-knight/bin/vmware-knight",
      "args": ["mcp"]
    }
  }
}

After installation, fully quit Claude Desktop and reopen it so the new MCP server is loaded. Start a fresh chat before testing.

A simple validation prompt is:

Using VMware Knight, list the configured VMware targets.

For an end-to-end live MCP test, use a request such as:

Use the VMware Knight MCP tool cluster_health_summary against target lab-vcenter with top_n=2.
Do not inspect local files. Return the two live top issues from vCenter.

If Claude returns live vCenter data through VMware Knight, the MCP integration is working correctly.

If vmware-knight is not found before starting the wizard, verify the installation with:

which vmware-knight
vmware-knight --help

vmware-knight-mcp is the stdio MCP server entry point used by MCP clients. You normally do not need to run it manually.

Claude Desktop on Windows

The wizard works on Windows too: vmware-knight wizard → 7 → 1, accept the default path, and confirm. It writes to the right place:

Claude Desktop install

Config file

Installer from claude.ai

%APPDATA%\Claude\claude_desktop_config.json

Microsoft Store

%LOCALAPPDATA%\Packages\Claude_*\LocalCache\Roaming\Claude\claude_desktop_config.json

On Windows, the generated entry also includes the .exe path and an env section with your home folder, so the server finds %USERPROFILE%\.vmware-knight:

{
  "mcpServers": {
    "vmware-knight": {
      "command": "C:\\Users\\USERNAME\\.local\\bin\\vmware-knight.exe",
      "args": ["mcp"],
      "env": {
        "USERPROFILE": "C:\\Users\\USERNAME",
        "SYSTEMROOT": "C:\\WINDOWS",
        "PYTHONUTF8": "1"
      }
    }
  }
}

Then fully quit Claude Desktop (right-click its tray icon → Quit), reopen it, and start a new chat.

Manual setup, if you prefer to edit the file yourself or the wizard picked the wrong file:

  1. In Claude Desktop, open Settings → Developer → Edit Config. This opens claude_desktop_config.json in the right place for your install (usually %APPDATA%\Claude\claude_desktop_config.json).

  2. Find your executable path with where.exe vmware-knight.

  3. Add VMware Knight under mcpServers. In JSON, every backslash must be doubled:

{
  "mcpServers": {
    "vmware-knight": {
      "command": "C:\\Users\\USERNAME\\.local\\bin\\vmware-knight.exe",
      "args": ["mcp"]
    }
  }
}

If the file already has other servers, add "vmware-knight": { ... } next to them inside the existing mcpServers object.

  1. Fully quit Claude Desktop (right-click its tray icon → Quit), reopen it, and start a new chat.


OpenAI Codex

The wizard can also configure Codex:

vmware-knight wizard

Then select:

7. Configure MCP clients
2. Codex

A typical Codex configuration looks like:

[mcp_servers.vmware-knight]
command = "/Users/yourname/.local/bin/vmware-knight"
args = ["mcp"]
enabled = true
startup_timeout_sec = 120

On Windows, the wizard also adds .exe to the path and passes your home folder to the server:

[mcp_servers.vmware-knight]
command = "C:\\Users\\yourname\\.local\\bin\\vmware-knight.exe"
args = ["mcp"]
enabled = true
startup_timeout_sec = 120

[mcp_servers.vmware-knight.env]
USERPROFILE = "C:\\Users\\yourname"
SYSTEMROOT = "C:\\WINDOWS"
PYTHONUTF8 = "1"
# ...plus APPDATA, LOCALAPPDATA, TEMP and TMP

Codex does not need Full Access to use VMware Knight: MCP tools run outside the Codex shell sandbox. If Codex only works with Full Access, the MCP entry is not loading; see docs/windows-codex.md.

Restart Codex after changing its MCP configuration.

Example:

Using VMware Knight, show me the VMs on esxi-lab-01.

7. How VMware Knight Works

The basic workflow is:

User
  |
  v
Claude / Codex
  |
  v
VMware Knight MCP Server
  |
  +--> resolve target by tag / name / host
  |
  v
pyVmomi / vSphere APIs
  |
  +--> vCenter Server
  |      |
  |      +--> Clusters
  |      +--> ESXi Hosts
  |      +--> Virtual Machines
  |      +--> Datastores
  |
  +--> Standalone ESXi Host

When the AI sends a target such as:

lab-vcenter

VMware Knight resolves that identifier to the configured VMware target before establishing the connection.


8. Capabilities Overview

VMware Knight includes operations across the following areas:

Area

Capabilities

VM Lifecycle

Power operations, VM creation, deletion, reconfiguration, snapshots, clone, migration

Deployment

OVA deployment, templates, linked clones, ISO attachment, batch deployment

Guest Operations

Command execution, file upload, file download

Plan / Apply

Multi-step execution plans with review and rollback support

Cluster Management

Cluster information, creation, deletion, HA/DRS configuration, host membership

Datastore

Browse datastore content and discover deployment images

Networking

Distributed port group and host VMkernel management workflows

Alarm Management

List, acknowledge, and reset triggered alarms

Investigation

VM, host, datastore, cluster, and cross-vCenter investigation workflows

Scanning

Scheduled alarm, event, and ESXi host-log scanning

Notifications

JSONL logging and webhook-based notification workflows

MCP

Structured VMware operations through Claude and Codex

CLI

Direct command-line operation without an AI client


9. Quick Investigation Workflows

VMware Knight includes read-oriented investigation commands that help identify problems before making changes.

Examples:

vmware-knight attention

Show issues requiring attention across configured vCenter targets.

vmware-knight summary

Show a cluster-oriented health summary.

vmware-knight investigate vm web-01 --hours 72

Correlate information around a VM.

vmware-knight investigate host esxi-01

Correlate information around a host.

vmware-knight investigate datastore datastore1

Correlate information around a datastore.

Offline HTML output is also available for supported investigation workflows:

vmware-knight investigate vm web-01 --html

Some investigation workflows delegate read-only aggregation to the companion vmware-monitor library.


10. VM Lifecycle

VMware Knight supports common virtual-machine lifecycle operations.

Operation

CLI Example

vCenter

ESXi

Power On

vm power-on <name>

Yes

Yes

Graceful Shutdown

vm power-off <name>

Yes

Yes

Force Power Off

vm power-off <name> --force

Yes

Yes

Create VM

vm create <name> --cpu --memory --disk

Yes

Yes

Delete VM

vm delete <name>

Yes

Yes

Reconfigure VM

vm reconfigure <name> --cpu --memory

Yes

Yes

Create Snapshot

vm snapshot-create <name> --name <snap>

Yes

Yes

List Snapshots

vm snapshot-list <name>

Yes

Yes

Revert Snapshot

vm snapshot-revert <name> --name <snap>

Yes

Yes

Delete Snapshot

vm snapshot-delete <name> --name <snap>

Yes

Yes

Task Status

vm task-status <task-id>

Yes

Yes

Clone VM

vm clone <name> --new-name <new>

Yes

Yes

vMotion

vm migrate <name> --to-host <host>

Yes

No

Set TTL

vm set-ttl <name> --minutes <n>

Yes

Yes

Cancel TTL

vm cancel-ttl <name>

Yes

Yes

List TTLs

vm list-ttl

Yes

Yes

Clean Slate

vm clean-slate <name> --snapshot baseline

Yes

Yes

Example using a target tag:

vmware-knight vm power-on web-01 --target lab-vcenter

11. Guest Operations

Guest operations require VMware Tools inside the guest operating system.

Examples:

vmware-knight vm guest-exec web-01 \
  --cmd /bin/bash \
  --args "-c 'whoami'" \
  --user root

Upload a file:

vmware-knight vm guest-upload web-01 \
  --local ./script.sh \
  --guest /tmp/script.sh \
  --user root

Download a file:

vmware-knight vm guest-download web-01 \
  --guest /var/log/syslog \
  --local ./syslog.txt \
  --user root

Guest usernames are explicit. VMware Knight does not silently assume root.


12. Plan / Apply Workflow

For multi-step operations, VMware Knight supports a plan-oriented workflow.

Typical sequence:

Create Plan
    |
    v
Validate Operations
    |
    v
Review Affected Objects
    |
    v
Confirm
    |
    v
Apply Sequentially
    |
    +--> Success
    |
    +--> Failure --> Rollback available operations

Core MCP operations include:

vm_create_plan
vm_apply_plan
vm_rollback_plan

Plans are stored under:

~/.vmware-knight/plans/

Successful plans are automatically removed, and stale plans are cleaned up.


13. VM Deployment and Provisioning

VMware Knight includes several deployment workflows.

Operation

Example

Deploy OVA

deploy ova ./ubuntu.ova --name lab-vm --datastore ds1

Deploy Template

deploy template golden-ubuntu --name new-vm

Linked Clone

deploy linked-clone --source base-vm --snapshot clean --name test-vm

Attach ISO

deploy iso my-vm --iso "[datastore1] iso/ubuntu.iso"

Mark Template

deploy mark-template golden-vm

Batch Clone

deploy batch-clone --source base-vm --count 5 --prefix lab

Batch Deploy

deploy batch deploy.yaml

Example:

vmware-knight deploy ova ./ubuntu.ova \
  --name ubuntu-lab-01 \
  --datastore datastore1 \
  --target lab-vcenter

14. Cluster Management

Cluster operations include:

Operation

Command

Cluster Info

cluster info <name>

Create Cluster

cluster create <name> --ha --drs

Delete Cluster

cluster delete <name>

Add Host

cluster add-host <cluster> --host <host>

Remove Host

cluster remove-host <cluster> --host <host>

Configure HA/DRS

cluster configure <name> --ha --drs

Example:

vmware-knight cluster info LAB-CLUSTER --target lab-vcenter

Removing a host from a cluster requires the appropriate VMware state, including maintenance-mode requirements where applicable.


15. Alarm Management

VMware Knight supports VMware alarm workflows.

List triggered alarms:

vmware-knight alarm list --target lab-vcenter

Acknowledge an alarm:

vmware-knight alarm acknowledge esxi-01 "Host memory usage"

Reset alarms:

vmware-knight alarm reset esxi-01 "Host memory usage"

Reset operations should be reviewed carefully because VMware alarm-clear APIs may affect multiple alarms within the selected scope.


16. Datastore Operations

Browse datastore content:

vmware-knight datastore browse datastore1 --path "iso/"

Scan for deployment images:

vmware-knight datastore scan-images --target lab-vcenter

Image discovery can locate content such as:

ISO
OVA
OVF
VMDK

17. Scheduled Scanning

VMware Knight includes scheduled scanning for operational visibility.

Start the daemon:

vmware-knight daemon start

Check status:

vmware-knight daemon status

Stop it:

vmware-knight daemon stop

Run a one-time scan:

vmware-knight scan now

The scanner can work across multiple configured targets and process operational information such as:

  • triggered alarms

  • vCenter events

  • ESXi host logs

  • scan findings

  • incomplete/unreachable target conditions

Structured scan output is written under the VMware Knight configuration directory.


18. Safety Model

Infrastructure automation requires explicit safety controls.

VMware Knight includes safeguards around write and destructive operations.

Depending on the operation and interface, these include:

  • dry-run or preview behavior

  • explicit confirmation

  • additional confirmation for destructive operations

  • plan-before-apply workflows

  • audit logging

  • rollback information where supported

  • explicit target selection

  • identifier collision validation

  • no silent target switching

The friendly-tag system is also part of the safety model because it lets operators use understandable infrastructure identifiers while VMware Knight still resolves the target against a validated inventory.

Always review destructive operations before approving them.


19. Common Workflows

Deploy a lab VM

vmware-knight datastore browse datastore1 \
  --pattern "*.ova" \
  --target lab-vcenter
vmware-knight deploy ova ./ubuntu.ova \
  --name lab-vm \
  --datastore datastore1 \
  --target lab-vcenter
vmware-knight vm snapshot-create lab-vm \
  --name baseline \
  --target lab-vcenter
vmware-knight vm set-ttl lab-vm \
  --minutes 480 \
  --target lab-vcenter

Work with multiple VMware environments

Configure tags such as:

prod-vcenter
dr-vcenter
lab-vcenter
esxi-lab-01
esxi-lab-02

Then ask Claude or Codex:

Using VMware Knight, show me all VMs on lab-vcenter.
Using VMware Knight, check active alarms on prod-vcenter.
Using VMware Knight, list VMs on esxi-lab-01.

This is easier and safer than repeatedly typing raw IP addresses.


20. CLI Quick Reference

Diagnostics:

vmware-knight doctor
vmware-knight doctor --skip-auth

Wizard:

vmware-knight wizard

MCP server:

vmware-knight mcp

VM operations:

vmware-knight vm power-on my-vm --target lab-vcenter
vmware-knight vm power-off my-vm --target lab-vcenter
vmware-knight vm create new-vm --cpu 4 --memory 8192 --disk 100 --target lab-vcenter
vmware-knight vm delete my-vm --target lab-vcenter
vmware-knight vm snapshot-create my-vm --name before-upgrade --target lab-vcenter
vmware-knight vm snapshot-list my-vm --target lab-vcenter
vmware-knight vm snapshot-revert my-vm --name before-upgrade --target lab-vcenter
vmware-knight vm clone my-vm --new-name my-vm-clone --target lab-vcenter
vmware-knight vm migrate my-vm --to-host esxi-02 --target lab-vcenter
vmware-knight vm set-ttl my-vm --minutes 60 --target lab-vcenter
vmware-knight vm list-ttl --target lab-vcenter

Deployment:

vmware-knight deploy ova ./ubuntu.ova --name my-vm --datastore ds1 --target lab-vcenter
vmware-knight deploy template golden-ubuntu --name new-vm --target lab-vcenter
vmware-knight deploy linked-clone --source base-vm --snapshot clean --name test-vm --target lab-vcenter
vmware-knight deploy iso my-vm --iso "[datastore1] iso/ubuntu.iso" --target lab-vcenter

Cluster:

vmware-knight cluster info LAB-CLUSTER --target lab-vcenter
vmware-knight cluster create LAB-CLUSTER --ha --drs --target lab-vcenter
vmware-knight cluster configure LAB-CLUSTER --ha --drs --target lab-vcenter

Alarms:

vmware-knight alarm list --target lab-vcenter

Datastore:

vmware-knight datastore browse datastore1 --path "iso/" --target lab-vcenter
vmware-knight datastore scan-images --target lab-vcenter

Scanning:

vmware-knight scan now
vmware-knight daemon start
vmware-knight daemon status
vmware-knight daemon stop

21. Project Structure

vmware-knight-mcp/
├── vmware_knight/
│   ├── config.py
│   ├── connection.py
│   ├── doctor.py
│   ├── init_wizard.py
│   ├── setup_wizard.py
│   ├── cli/
│   ├── ops/
│   ├── scanner/
│   ├── notify/
│   └── mcp_server/
├── skills/
│   └── vmware-knight/
├── examples/
├── tests/
├── config.example.yaml
├── pyproject.toml
├── RELEASE_NOTES.md
└── README.md

22. Technology

VMware Knight is built primarily with:

  • Python

  • pyVmomi

  • Typer

  • FastMCP / Model Context Protocol

  • YAML-based target configuration

  • local credential/environment storage

  • automated pytest coverage


23. Testing

Run the project tests with:

uv run pytest -q

The project includes tests for areas such as:

  • configuration loading

  • target resolution

  • friendly tag resolution

  • identifier collision handling

  • wizard operations

  • credential migration

  • MCP configuration

  • lifecycle safety gates

  • plan/apply behavior

  • cluster operations

  • guest operations

  • alarms

  • deployment

  • regression coverage


24. Updating VMware Knight

If installed directly from GitHub with uv, reinstall from the repository:

uv tool install --force \
  git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

The same command works in PowerShell on Windows, written on one line:

uv tool install --force git+https://github.com/CyberKnightLabs/vmware-knight-mcp.git

For a cloned repository:

cd vmware-knight-mcp
git pull origin main
uv sync

25. Troubleshooting

Check the installation

vmware-knight --help

On macOS, if Terminal says zsh: command not found: vmware-knight (or uv), ~/.local/bin is not on your PATH. Run Step 5 of the macOS user guide, then check again:

uv tool update-shell
export PATH="$HOME/.local/bin:$PATH"
which vmware-knight

If git asks you to install the command line developer tools, see Step 1 of the macOS user guide.

On Windows, if PowerShell says uv, git or vmware-knight is not recognized, the program is usually installed but the window has an old PATH. Reload it and check again:

$env:Path = [Environment]::GetEnvironmentVariable("Path", "Machine") + ";" + [Environment]::GetEnvironmentVariable("Path", "User")
where.exe uv git vmware-knight

If vmware-knight is still missing, run uv tool update-shell and reload again. If git is still missing, see Step 4 of Option C — Windows. The same applies to uv tool install failing with Git executable not found.

Check VMware configuration

vmware-knight doctor

Check targets

vmware-knight wizard

Choose:

1. List VMware targets

Test connectivity

From the wizard choose:

6. Test connections

MCP client does not show VMware Knight

Confirm that:

  • the vmware-knight executable path exists

  • the MCP configuration uses the correct executable

  • the MCP server name is vmware-knight

  • the client has been restarted after changing its MCP configuration

For Codex, a typical block is:

[mcp_servers.vmware-knight]
command = "/Users/yourname/.local/bin/vmware-knight"
args = ["mcp"]
enabled = true
startup_timeout_sec = 120

On Windows, also check:

  • the command path ends in .exe

  • in Codex's TOML, the path is either in single quotes ('C:\Users\...') or has doubled backslashes ("C:\\Users\\..."); single backslashes inside double quotes break the whole file

  • codex mcp get vmware-knight shows the entry; if it reports a parse error, re-run the wizard or the Windows installer script

TLS errors in a lab

If your lab uses a self-signed certificate, the wizard allows TLS certificate verification to be disabled for that target.

Do this only when you understand and accept the security implications.


26. Repository

GitHub:

https://github.com/CyberKnightLabs/vmware-knight-mcp

Clone:

git clone https://github.com/CyberKnightLabs/vmware-knight-mcp.git

27. License

MIT

See LICENSE for the complete license text.

Available Tools

60 tools
acknowledge_vcenter_alarmA

[WRITE] Acknowledge a triggered vCenter alarm — marks it as seen WITHOUT clearing it.

This only marks the alarm; it does not clear it. The alarm stays in the active list with acknowledged=true until its condition clears or it is reset. To remove it entirely after fixing the root cause use reset_vcenter_alarm instead. Get exact entity_name and alarm_name from list_vcenter_alarms first; an unknown pair returns a not-found error.

Returns: Dict: entity_name, alarm_name, action ("acknowledged"), acknowledged (true).

Inputs: alarm_name (required), entity_name (required), target.

add_host_vmkA

[WRITE] Add a static-IP VMkernel adapter on a DVS portgroup - preview/confirm gated.

Deliberately minimal shape for throwaway test vmks on L2-only segments (e.g. a TEP VLAN): static IPv4, NO gateway, NO services enabled. The DVS port allocation is handled internally - pass the distributed portgroup name. confirm=False validates (host + portgroup exist, IP/netmask/MTU legal, IP not already on the host) and returns the exact spec without writing; confirm=True creates and returns the assigned device name. Verify with list_host_vmks; remove with remove_host_vmk. Audited.

Returns: Preview dict (action="preview") or result dict (action="created", device=e.g. "vmk2"). Errors return a dict with "error" + hint.

Inputs: ip (required), netmask (required), host_name (required), portgroup (required), +3 more.

attach_iso_to_vmA

[WRITE] Mount a datastore ISO into a VM's virtual CD-ROM drive.

Reconfigures the existing CD-ROM (replacing any mounted ISO) or adds one on the VM's IDE controller; fails with a clear message if the VM has no IDE controller. Works whether the VM is powered on or off. Find ISO paths first with browse_datastore using pattern "*.iso". Returns a status string confirming attachment, or a VM-not-found / no-IDE-controller error.

Inputs: vm_name (required), iso_ds_path (required), target. Returns: result

batch_clone_vmsA

[WRITE] Batch clone multiple VMs from a source VM (gold image).

Each clone: full copy → optional reconfigure → optional snapshot → optional power on. Returns one dict per VM with its status. Clones run sequentially, so a long vm_names list may take a while — prefer batch_linked_clone_vms for disposable test copies.

Inputs: vm_names (required), source_vm_name (required), cpu, target, +3 more. Returns: result

batch_deploy_from_specA

[WRITE] Deploy multiple VMs in one call from a declarative YAML spec file.

Use for fleet provisioning (several VMs, shared defaults); for a single VM prefer deploy_vm_from_template, vm_clone, deploy_vm_from_ova, or deploy_linked_clone. The channel is chosen by spec keys: "source" (full clone), "template", "linked_clone: {source, snapshot}", per-VM "ova", else empty-VM creation (optionally "iso"). A "defaults" block sets cpu/memory_mb/disk_gb/network/ datastore/snapshot/power_on, overridable per VM. VMs deploy sequentially and one VM's failure does not stop the rest.

Returns: One dict per VM: name, status ("ok" or "error"), and messages with per-step results.

Inputs: spec_path (required), target. Returns: result

batch_linked_clone_vmsA

[WRITE] Batch create linked clones from a VM snapshot (fastest batch provisioning).

Clones share the source disk via copy-on-write, so the source must stay intact. Returns one dict per clone. Prefer batch_clone_vms for independent copies.

Inputs: vm_names (required), snapshot_name (required), source_vm_name (required), cpu, +4 more. Returns: result

browse_datastoreA
Read-onlyIdempotent

[READ] Browse files in a vSphere datastore directory.

Use this to find OVA/ISO/VMDK paths before calling deploy_vm_from_ova or attach_iso_to_vm; for an estate-wide image sweep use scan_datastore_images.

Returns the list envelope: 'items' is one row per file, and 'returned'/'total'/'truncated' state completeness. Every match in the searched folders is returned, so truncated is always false.

Inputs: datastore_name (required), path, target, pattern.

cluster_add_hostA

[WRITE] Move an ESXi host that vCenter already manages into a cluster.

The host must already be in vCenter inventory (standalone or in another cluster) — this does NOT register brand-new hosts and takes no host credentials; use the vCenter UI for first-time registration. Idempotent: a host already in the cluster returns success without change. Maintenance mode is not required to join (it IS required by cluster_remove_host). Check membership first with cluster_info. Returns a status string: moved, already-in-cluster, or a not-found error.

Inputs: host_name (required), cluster_name (required), target. Returns: result

cluster_configureA

[WRITE] Reconfigure cluster HA/DRS settings.

Returns a status string naming what changed. Pass only the fields to change; None leaves a setting untouched — then verify with cluster_info. drs_behavior applies only when DRS is enabled.

Inputs: name (required), ha, drs, target, +1 more. Returns: result

cluster_createA

[WRITE] Create a new empty cluster in a datacenter, optionally enabling HA and DRS.

Fails with a clear error (no partial state) if the name already exists or drs_behavior is invalid. Then add hosts with cluster_add_host, change HA/DRS later with cluster_configure, and verify with cluster_info. Returns a status string naming the features enabled.

Inputs: name (required), ha, drs, target, +2 more. Returns: result

cluster_deleteA
Destructive

[WRITE] Delete an empty cluster (no hosts must remain).

Without confirm=True this only previews: it returns blast_radius (cluster name and id, host/VM/datastore counts and names, blockers) and deletes nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Refused: a cluster that still has hosts or VMs (evacuate members with cluster_remove_host first), or one whose members could not be read. Check cluster_info first. Returns a dict (action, blast_radius).

Inputs: name (required), target, confirm.

cluster_health_summaryA
Read-onlyIdempotent

[READ] One-glance health rollup for every cluster — "is anything on fire?".

Aggregates hosts, VM power state, live CPU/memory pressure, triggered alarms and datastores thin-provisioned past 100% of capacity per cluster, assigns each a status ("ok"/"warn"/"critical"), and flattens the anomalies into a ranked top_issues focus list — the fast triage view for "what's wrong right now?". Read-only (delegates to the vmware-monitor library). Use it FIRST for a cross-cluster glance, then drill in with vm_investigation_bundle or host_investigation_bundle.

Returns {totals, top_issues, issues_total, clusters, snapshot, customization_hint}. Lead with top_issues (worst first, each with a drill-down hint), clusters as context, customization_hint last. Point-in-time — no trending.

Inputs: top_n, target, include_vms, cluster_filter.

cluster_infoA
Read-onlyIdempotent

[READ] Get detailed cluster information: member hosts, HA/DRS config, resource capacity.

Read-only, no side effects. Use before cluster_add_host / cluster_remove_host (shows membership and per-host maintenance mode) and to verify cluster_configure changes.

Returns: Dict with name, host_count, hosts (each: name, connection_state, power_state, maintenance_mode), ha_enabled, ha_admission_control, drs_enabled, drs_behavior, total/effective CPU (MHz) and memory (GB). Errors return a dict with "error" + hint.

Inputs: name (required), target.

cluster_remove_hostA
Destructive

[WRITE] Remove a host from a cluster (host must be in maintenance mode).

Without confirm=True this only previews: it returns blast_radius (host name and id, maintenance mode, VM count, powered-on VM count, blockers) and moves nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Refused: a host not in maintenance mode, a host with powered-on VMs, and a host whose state could not be read. Run cluster_info first for the exact member host names. The host is not deleted — it stays in vCenter inventory standalone; use cluster_add_host to move it back. Returns a dict.

Inputs: host_name (required), cluster_name (required), target, confirm.

convert_vm_to_templateA

[WRITE] Convert a powered-off VM to a vSphere template.

Returns a status string. Use this to freeze a golden image: afterwards the VM cannot be powered on and serves only as a clone source for deploy_vm_from_template.

Inputs: vm_name (required), target. Returns: result

create_drs_ruleA

[WRITE] Create a VM-VM DRS rule (affinity or anti-affinity) - preview/confirm gated.

rule_type "affinity" keeps the listed VMs together; "antiAffinity" keeps them apart (e.g. redundant appliance pairs on separate hosts). Requires >=2 distinct VMs, all members of the cluster. VM-Host rules hang off cluster VM/host groups and are not created here. Verify with list_drs_rules. Audited.

Returns: Preview dict (action="preview", would_create) or result dict (action="created", created incl. the assigned key). Errors return a dict with "error" + hint.

Inputs: cluster (required), vm_names (required), rule_name (required), rule_type (required), +3 more.

create_dvs_portgroupA

[WRITE] Create a VLAN-tagged portgroup on a dvSwitch - preview/confirm gated.

confirm=False (default) validates everything (switch exists, name free, binding and VLAN legal) and returns the exact spec that WOULD be created without writing anything. confirm=True creates the portgroup and waits for the task. Verify afterwards with list_dvs_portgroups. Audited.

binding="ephemeral" creates a portgroup with no pre-created port pool, attachable from the ESXi host client even when vCenter is down - use for a self-hosted VCSA's own management portgroup. num_ports is ignored for ephemeral. lateBinding is deprecated by vSphere and not offered.

Returns: Preview dict (action="preview", would_create) or result dict (action="created", created). Errors return a dict with "error" + hint.

Inputs: name (required), vlan_id (required), dvs_name (required), target, +3 more.

cross_vcenter_attentionA
Read-onlyIdempotent

[READ] "What needs attention now?" across EVERY configured vCenter — one list.

Runs cluster_health_summary against every configured target and returns one globally ranked top_issues list (worst first, each tagged with its vcenter) plus a per-target rollup — "where do I look first, anywhere in the estate?". Degrades gracefully: an unreachable target is listed under unreachable and the rest still aggregate. Delegates to the vmware-monitor library (read-only). Lead with top_issues, then drill in with vm_investigation_bundle. Point-in-time.

Inputs: top_n, cluster_filter.

datastore_investigation_bundleA
Read-onlyIdempotent

[READ] "What is happening around this datastore?" — one correlated drill-down.

Correlates a datastore's capacity/free space/accessibility, the hosts that mount it, a rollup of the VMs it backs, alarms across datastore/host, and a merged event timeline. Delegates to the vmware-monitor library (read-only); do not dump the result raw. (Per-datastore latency is a separate perf report.)

Use this AFTER cluster_health_summary flags storage pressure. Point-in-time.

Inputs: datastore_name (required), hours, target.

delete_drs_ruleA
Destructive

[WRITE] Delete a VM-VM DRS rule - confirm-gated, guarded.

REFUSES non-VM-VM rules: VM-Host rules can carry licensing/compliance placement constraints (must-run-on licensed hosts) and hang off cluster groups - manage those in the vSphere UI. The preview and result both record the full rule definition so a mistaken delete can be recreated from the audit trail. Audited.

Returns: Preview dict (action="preview", would_delete) or result dict (action="deleted", deleted). Errors return a dict with "error" + hint.

Inputs: cluster (required), rule_name (required), target, confirm.

deploy_linked_cloneA

[WRITE] Create a linked clone from a VM snapshot — near-instant, minimal disk usage.

The clone writes to a copy-on-write delta over the source's base disk, so it depends on the source staying intact. Fastest provisioning for test/dev fleets; use vm_clone for fully independent copies. Requires the named snapshot — run vm_list_snapshots first. Returns a status string with the new clone name.

Inputs: new_name (required), snapshot_name (required), source_vm_name (required), cpu, +4 more. Returns: result

deploy_vm_from_ovaA

[WRITE] Create a new VM by importing a local .ova file (OVF parse + VMDK upload).

Use for local OVA files; for vSphere templates use deploy_vm_from_template, to copy an existing VM vm_clone. Returns a status string naming the new VM. Upload time scales with OVA size; fails before creating anything if the datastore is not found.

Inputs: vm_name (required), ova_path (required), datastore_name (required), target, +4 more. Returns: result

deploy_vm_from_templateA

[WRITE] Deploy a new VM by cloning from a vSphere template.

Returns a status string. Use for VMs marked as templates; for a running source VM use vm_clone. Requires an existing template — convert_vm_to_template makes one.

Inputs: new_name (required), template_name (required), cpu, target, +4 more. Returns: result

host_investigation_bundleA
Read-onlyIdempotent

[READ] "What is happening around this ESXi host?" — one correlated drill-down.

Correlates a host's state (connection, CPU/memory, ESXi version, uptime), its cluster context, a rollup of the VMs it runs, the datastores it mounts, alarms across host/cluster/datastore, live performance, and a merged event timeline. Delegates to the vmware-monitor library (read-only); do not dump the result raw.

Use this AFTER cluster_health_summary flags a host. Point-in-time.

Inputs: host_name (required), hours, target.

list_drs_rulesA
Read-onlyIdempotent

[READ] List a cluster's DRS rules: VM-VM affinity/anti-affinity and VM-Host.

Per rule: key, name, type (affinity / antiAffinity / vmHost), enabled, mandatory, and the member VM names (VM-VM) or group names (VM-Host). The verify pair for create/delete/set_drs_rule_enabled.

Returns: Dict with cluster, count, and rules sorted by name. Errors return a dict with "error" + hint.

Inputs: cluster (required), target.

list_dvs_portgroupsA
Read-onlyIdempotent

[READ] List distributed virtual portgroups, optionally scoped to one dvSwitch.

Per portgroup: name, parent dvSwitch, binding type (earlyBinding / ephemeral), VLAN setting (id, trunk ranges, or pvlan), configured port count, and whether it is the switch's uplink portgroup. Use to verify create_dvs_portgroup results or to survey network config before changes.

Returns: The family list envelope {items, returned, limit, total, truncated, hint}; each item is one portgroup. portgroups is kept as a deprecated alias for items. Errors return a dict with "error" + hint.

Inputs: limit, offset, target, dvs_name.

list_host_vmksA
Read-onlyIdempotent

[READ] List VMkernel adapters, optionally scoped to one ESXi host.

Per vmk: device, IP/netmask/dhcp, MTU, MAC, portgroup (standard or DVS), netstack, and which host services it is selected for (management, vmotion, vsan, ...). The verify pair for add_host_vmk/remove_host_vmk.

Gotcha - this list is not automatically a complete estate inventory. vCenter answers property reads for a host it has lost contact with out of its own cache, so hosts it never reached appear here as rows with reachable: false, device: null and a note naming the connectionState, rather than being dropped. Check hosts_unreachable (and the unreachable_note present only when it is non-zero) before reporting the result as the full picture, and do not read a null field on such a row as a measurement - it means nobody looked. Adapters shown for an unreachable host are vCenter's last cached view.

Returns: The family list envelope {items, returned, limit, total, truncated, hint} plus hosts_unreachable (int) and, when that is non-zero, unreachable_note (str). Each item is one VMkernel adapter, or one unread host when reachable is false; services is null when a host's service map could not be read. truncated stays a paging fact - an incomplete estate is reported by hosts_unreachable, not by it. vmks is kept as a deprecated alias for items. Errors return "error" + hint.

Inputs: limit, offset, target, host_name.

list_vcenter_alarmsA
Read-onlyIdempotent

[READ] List active/triggered alarms across the vCenter inventory.

Start here for alarm work: it supplies the exact entity_name/alarm_name pair that acknowledge_vcenter_alarm and reset_vcenter_alarm require.

Returns the list envelope: 'items' holds severity (critical/warning/info), entity name and type, alarm name, acknowledged flag, and trigger time; 'returned'/'limit'/'total'/'truncated'/'hint' state completeness, so a limited page is never mistaken for the whole picture. 'total' is the real active-alarm count — every alarm is collected before the limit is applied.

Inputs: limit, target.

remove_host_vmkA
Destructive

[WRITE] Remove a VMkernel adapter - confirm-gated, guarded, fail-closed.

REFUSES (unless force_unprotected=True) when the vmk is selected for any host service (management/vmotion/vsan/...), lives on a non-default netstack (NSX TEPs on vxlan, dedicated vmotion/provisioning stacks - never visible in the service map), carries a default gateway route, or when any of that CANNOT be verified - unverifiable is treated as unsafe, never as clear. Test vmks created by add_host_vmk trip none of these and remove cleanly without force.

ABSOLUTE, no override: the host's only management-enabled vmk is never removable - this call rides the interface it would delete.

force_unprotected=True (together with confirm=True) overrides the non-absolute protections for deliberate teardown; the override and every bypassed protection are recorded in the result (and the audit trail).

Returns: Preview dict (action="preview") or result dict (action="removed", plus forced/protections_bypassed when overridden). Errors return a dict with "error" + hint.

Inputs: vmk (required), host_name (required), target, confirm, +1 more.

reset_vcenter_alarmA

[WRITE] Clear triggered vCenter alarms back to normal state.

Use this after resolving the underlying issue; to merely mark an alarm seen use acknowledge_vcenter_alarm instead. Get entity_name and alarm_name from list_vcenter_alarms first.

Gotcha: vSphere has no per-alarm clear — this clears ALL triggered alarms matching the named alarm's entity type (host/VM/all) and current status (red/yellow), so confirm the blast radius with the user first. Returns a dict whose 'scope' field states exactly what was cleared.

Inputs: alarm_name (required), entity_name (required), target.

scan_datastore_imagesA
Read-onlyIdempotent

[READ] Scan all accessible datastores for deployable images (OVA/ISO/OVF/VMDK).

Returns the images found and refreshes the cache at ~/.vmware-knight/image_registry.json. Use this when you do not know which datastore holds an image; prefer browse_datastore once you do, because this walks every datastore and may take minutes on a large estate.

Returns: The family list envelope {items, returned, limit, total, truncated, hint} plus last_scan; each item is one image. images is kept as a deprecated alias for items.

Inputs: target.

set_drs_rule_enabledA
Idempotent

[WRITE] Enable or disable an existing DRS rule - preview/confirm gated.

The day-2 toggle: anti-affinity rules often must be disabled while a cluster is temporarily too small to satisfy them, then re-enabled when hosts return. Idempotent - matching state returns a noop, no write. Names are matched exactly; ambiguous names refuse. Audited.

Returns: Preview dict (action="preview"), noop dict (action="noop"), or result dict (action="set", rule_now). Errors return "error" + hint.

Inputs: cluster (required), enabled (required), rule_name (required), target, +1 more.

set_vmk_serviceA
Idempotent

[WRITE] Enable/disable a host service on an existing vmk - preview/confirm gated.

Completes the add_host_vmk story: adapters are created serviceless by design, then tagged here (e.g. enable "vmotion" on a new vMotion vmk). Idempotent - re-applying the current state returns a no-write noop. Verify with list_host_vmks (the services field). Audited.

Valid services are the vSphere nicType names: management, vmotion, vsan, vSphereProvisioning, faultToleranceLogging, vSphereReplication, vSphereReplicationNFC, vSphereBackupNFC, ptp, and the nvme/vsan variants. Note "vSphereProvisioning", not "provisioning".

FAIL CLOSED: refuses both directions when the host's service map cannot be read. ABSOLUTE, no override: disabling management on the host's only management-enabled vmk - the call rides the interface it would untag.

Returns: Preview dict (action="preview"), noop dict (action="noop") when the state already matches, or result dict (action="set", services_now). Errors return a dict with "error" + hint.

Inputs: vmk (required), enabled (required), service (required), host_name (required), +2 more.

vm_apply_planA
Destructive

[WRITE] Execute a previously created plan step by step.

Without confirm=True this only previews: it returns blast_radius listing every step (index, action, target object), the count and indices of the destructive ones (delete, power off, revert, guest commands...), and blockers — and runs nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Each step is shown with its full parameters (passwords redacted). Each destructive step is measured as its own tool would measure it (vm_delete, vm_power_off, vm_revert_snapshot, vm_guest_exec, cluster_delete ...), and that tool's blockers refuse the plan. A step on something an earlier step creates or changes is marked check "deferred": it is measured immediately before it runs, and the plan stops there if it fails.

Refused: a target other than the one the plan was created against (no target is a target of its own), a step its tool would refuse, anything it could not read, a delete_vm step without its acknowledge_blast_radius (from a vm_delete preview), and any iscsi_* or storage_rescan step — those are gated in vmware-storage; run storage_iscsi_* / storage_rescan there.

With confirm=True steps run sequentially. On failure: stops immediately, keeps the plan file with per-step results, and returns rollback_available. On success: deletes the plan file. If a step fails and rollback_available is true, ask the user whether to rollback, then call vm_rollback_plan.

Inputs: plan_id (required), target, confirm.

vm_cancel_ttlA
Idempotent

[WRITE] Cancel an existing TTL for a VM (prevents auto-deletion).

Returns a status string. Use vm_list_ttl first for the exact vm_name. This only removes the schedule and never touches the VM itself.

Inputs: vm_name (required). Returns: result

vm_clean_slateA
Destructive

[WRITE] Revert a VM to its baseline snapshot (Clean Slate).

Without confirm=True this only previews: it returns blast_radius (VM identity, power state and whether it is powered off first, the snapshot and when it was taken, snapshot count, blockers) and changes nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

With confirm=True: powers off the VM first if it is running, then reverts to the named snapshot. Use this to reset a lab/dev VM to a clean starting state after a task completes. Irreversible — everything written since the snapshot is lost. Refused: no snapshot of that name, more than one, or a VM whose state cannot be read. Returns a dict (action, blast_radius).

Inputs: vm_name (required), target, confirm, snapshot_name.

vm_cloneA

[WRITE] Clone a VM. Without to_host/to_datastore the clone lands on the source's host+datastore.

Returns a status string naming the clone. Full independent copy — slow and full disk cost; prefer deploy_linked_clone for near-instant test copies and batch_clone_vms for many at once. Cloning a running VM may capture a crash-consistent disk.

Inputs: vm_name (required), new_name (required), target, to_host, +2 more. Returns: result

vm_createA

[WRITE] Create a new empty VM with the given hardware sizing.

Creates a powered-off VM with one disk and one NIC. To populate it, attach an ISO (attach_iso_to_vm) and power it on, or use deploy_vm_from_ova or vm_clone for a ready-to-run guest. Fails before creating anything if the datastore is not found. Returns a status string with the new VM name.

Inputs: vm_name (required), cpu, target, disk_gb, +4 more. Returns: result

vm_create_planA

[WRITE] Create an execution plan for multi-step VM operations.

Use for 2+ steps or 2+ VMs. Validates actions, checks the targets exist in vSphere, and generates a plan with rollback info per step.

Each operation is a dict with "action" key plus action-specific params. Allowed actions: power_on, power_off, reset, suspend, create_vm, delete_vm, reconfigure, create_snapshot, delete_snapshot, revert_snapshot, clone, migrate, deploy_ova, deploy_template, linked_clone, attach_iso, convert_to_template.

Returns plan dict with plan_id, steps, summary (vms_affected, irreversible_steps, rollback_available). Show to user for confirmation before calling vm_apply_plan.

Inputs: operations (required), target.

vm_create_snapshotA

[WRITE] Create a snapshot of a VM.

Returns a status string. Use this before a risky change so vm_revert_snapshot can undo it, then reclaim the space with vm_delete_snapshot — snapshots left for days grow delta disks and must not be treated as backups.

Inputs: vm_name (required), snapshot_name (required), memory, target, +2 more. Returns: result

vm_deleteA
Destructive

[WRITE] Delete a VM and its disks and snapshots (irreversible).

Without confirm=True this only previews: it returns blast_radius (identity, host, disks, total size, snapshot count, blockers) and destroys nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user said "delete" earlier: they have not seen what it destroys yet.

To delete, call again with confirm=True and acknowledge_blast_radius set to the preview's acknowledge_with object, unchanged. The VM is re-measured first; if it changed (another snapshot, a different VM under the same name), nothing is deleted and you must preview again.

Refused outright: a powered-on or suspended VM (power it off with vm_power_off first), a VM whose disks or identity cannot be read, and a name that matches more than one VM. Use vm_set_ttl instead when the VM should only expire later.

Inputs: vm_name (required), target, confirm, acknowledge_blast_radius.

vm_delete_snapshotA
Destructive

[WRITE] Permanently delete a named snapshot, consolidating its delta disk into the parent.

Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, the snapshot's name, id and creation time, remove_children, how many child snapshots sit below it and how many snapshots would be removed) and deletes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Frees disk space and does NOT change the VM's current state (unlike vm_revert_snapshot). Works while the VM is powered on. Refused: a snapshot name that is not found, a name that matches more than one snapshot on the VM (vSphere allows duplicates; rename one first), and a snapshot tree that cannot be read. Run vm_list_snapshots first for exact names.

Consolidation is slow for old/large deltas (often minutes). By default (wait=False) this returns a task id immediately so it does not block your context — poll it with vm_task_status. Set wait=True only for small snapshots (blocks up to 30 min).

Returns: Dict with action (preview, snapshot_delete_started, snapshot_deleted), blast_radius, and result (carries the task id to poll via vm_task_status).

Inputs: vm_name (required), snapshot_name (required), wait, target, +2 more.

vm_guest_downloadA

[WRITE] Download a file from a VM and write it to a local path.

Reads from the guest, writes the local filesystem — the write is why this is not a read tool. Returns a status string. Requires VMware Tools running in the guest OS. Use vm_guest_upload for the reverse direction; to capture command output use vm_guest_exec_output instead — it redirects and downloads for you.

Refuses a destination that already exists unless overwrite=True, and never writes through a symlink or over a directory. Pick a path that does not exist yet rather than passing overwrite=True by default.

Inputs: vm_name (required), username (required), guest_path (required), local_path (required), +3 more. Returns: result

vm_guest_execA
Destructive

[WRITE] Execute a command inside a VM via VMware Tools.

Requires VMware Tools running in the guest OS. Returns exit_code, stdout, stderr, timed_out, and blast_radius.

Without confirm=True this only previews: blast_radius names the VM (name, instance UUID), the guest account, the exact command, arguments and working directory, VMware Tools status and any blockers; nothing runs. Show it to the user. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused outright: VM not powered on, VMware Tools not running, an identity or status that cannot be read, or a name that matches more than one VM.

Note: the Guest Ops API does not capture stdout/stderr directly, so use this only for fire-and-forget commands — prefer vm_guest_exec_output whenever you need the output.

Inputs: command (required), vm_name (required), username (required), target, +4 more.

vm_guest_exec_outputA
Destructive

[WRITE] Execute a shell command inside a VM and capture stdout + stderr.

Automatically detects guest OS (Linux/Windows) and selects the correct shell. Output is captured by redirecting to a temp file, downloading it, then cleaning up — no manual redirection needed. Prefer this over vm_guest_exec whenever you need the output. Requires VMware Tools running and a writable temp directory in the guest.

Returns exit_code, stdout, stderr, timed_out, os_family, and blast_radius.

Without confirm=True this only previews: blast_radius names the VM (name, instance UUID), the guest account, the exact command and the shell it runs through, VMware Tools status and any blockers; nothing runs. Show it to the user. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused outright: VM not powered on, VMware Tools not running, an unreadable identity or status, or a name that matches more than one VM.

Inputs: command (required), vm_name (required), username (required), target, +3 more.

vm_guest_provisionA
Destructive

[WRITE] Provision a VM by running an ordered sequence of guest operations.

Prefer this over repeated vm_guest_exec / vm_guest_upload calls when the steps form one provisioning run. Steps stop on the first failure, so a partial run leaves the guest half-configured. Requires VMware Tools running in the guest.

Without confirm=True this only previews: blast_radius names the VM (name, instance UUID), the guest account and every step it would run, in order, with counts per type, local file sizes and any blockers; nothing runs. Show it to the user. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused outright: VM not powered on, VMware Tools not running, an empty step list, a step with an unknown type or a missing key, an upload whose local file is missing or unreadable, a service step on a Windows guest, an unreadable identity or status, or a name that matches more than one VM.

Step types:

  • exec: {"type": "exec", "command": "apt-get install -y nginx"}

  • upload: {"type": "upload", "local_path": "...", "guest_path": "..."}

  • service: {"type": "service", "name": "nginx", "action": "start"}

Returns: dict with success, completed_steps, total_steps, results, error, and blast_radius.

Inputs: steps (required), vm_name (required), password (required), username (required), +3 more.

vm_guest_uploadA
Destructive

[WRITE] Upload a file from local machine to a VM via VMware Tools.

Returns a dict with action, message and blast_radius (a status string before the confirmation gate). Requires VMware Tools running in the guest OS. An existing file at guest_path is replaced. Use vm_guest_download for the reverse direction, and vm_guest_provision instead when uploads and commands belong to one ordered provisioning run.

Without confirm=True this only previews: blast_radius names the VM (name, instance UUID), the guest account, the local path and size, the guest path, VMware Tools status and any blockers; nothing is transferred. Show it to the user. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused outright: VM not powered on, VMware Tools not running, a local file that is missing or unreadable, an unreadable identity or status, or a name that matches more than one VM.

Inputs: vm_name (required), username (required), guest_path (required), local_path (required), +3 more.

vm_investigation_bundleA
Read-onlyIdempotent

[READ] "What is happening around this VM?" — one correlated drill-down.

Correlates everything around one VM so you don't stitch it together yourself: the VM's state, its host, cluster context, backing datastores, snapshots, triggered alarms, live performance, and a merged event timeline across VM, host, cluster and datastores (newest first). Batched, cheap even on large fleets. Delegates to the vmware-monitor library (read-only). Explain the result in operational language; do not dump it raw.

Use this AFTER cluster_health_summary points at a problem VM. Point-in-time.

Inputs: vm_name (required), hours, target.

vmk_pingA
Read-onlyIdempotent

[READ] DF-bit-capable ping sourced from a host vmk - MTU path validation.

Runs esxcli network diag ping on the ESXi host through the vSphere API (no host SSH). df=True sets Don't-Fragment so an oversized packet FAILS instead of fragmenting - that failure is the diagnostic:

  • df=True size=1572 proves a >=1600 MTU path (overlay/TEP floor)

  • df=True size=8972 proves full jumbo (9000 minus 28 bytes overhead) A too-big result reports 'Message too long' in the fault field rather than erroring - read success + fault together.

Returns: Dict with request, success, and summary (transmitted/received/loss/ rtt) or fault (the esxcli failure text). Errors return "error" + hint.

Inputs: dest_ip (required), host_name (required), source_vmk (required), df, +4 more.

vm_list_plansA
Read-onlyIdempotent

[READ] List all pending/failed plans.

Use this first to find a plan_id for vm_apply_plan or vm_rollback_plan. Returns the list envelope: 'items' holds plan summaries (plan_id, created_at, status, steps count, VMs affected), and 'returned'/'total'/ 'truncated' state whether the listing is complete. Every plan file is read, so truncated is always false. Listing never deletes: stale plans (>24h) are swept by vm_create_plan, not by this tool.

Inputs: no named parameters.

vm_list_snapshotsA
Read-onlyIdempotent

[READ] List the full snapshot tree of a VM, including nested child snapshots.

Read-only, no side effects. Call this before vm_revert_snapshot, vm_delete_snapshot, or deploy_linked_clone to get exact snapshot names. 'items' is empty when the VM has no snapshots.

Returns: The list envelope. 'items' is one dict per snapshot: name, description, created, state (power state at snapshot time), level (0 = root). The whole tree is walked, so 'total' is the real count and 'truncated' is always false.

Inputs: vm_name (required), target.

vm_list_ttlA
Read-onlyIdempotent

[READ] List all VMs with TTLs registered, including expiry time and status.

Use this first to find the exact vm_name for vm_cancel_ttl. Returns the list envelope: 'items' holds TTL entries with remaining_minutes and expired flag, and 'returned'/'total'/'truncated' state whether the listing is complete. The whole TTL store is read, so truncated is always false.

Inputs: no named parameters.

vm_migrateA

[WRITE] Migrate (vMotion) a VM to another host, optionally with storage vMotion.

Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, source host and datastores, target host with its connection and maintenance state, target datastore, and live vMotion vs cold migration) and moves nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Refused: a target host that is not found, not connected, in maintenance mode or outside a cluster; a target datastore that is not found; a target host that does not mount the VM's datastores when to_datastore is omitted (vCenter rejects cross-host vMotion without shared storage — pass to_datastore); and anything above that cannot be read. The VM's current host with no to_datastore returns action "noop". Run cluster_info first for host names.

Returns: Dict with action (preview, noop, migrated), blast_radius, and result.

Inputs: to_host (required), vm_name (required), target, confirm, +1 more.

vm_power_offA
Destructive

[WRITE] Power off a VM — graceful guest shutdown by default, hard power-off with force=True.

Without confirm=True this only previews: it returns blast_radius (VM name and instance UUID, host, power state, VMware Tools status, and whether this is a guest shutdown or a hard power-off) and changes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Graceful mode calls VMware Tools guest shutdown and waits up to 120s; if it does not finish, action is "still_running". Refused: a graceful shutdown when Tools is not running or the VM is suspended (preview force=True instead), and a VM whose identity or power state cannot be read. An already-off VM returns action "noop". Use vm_power_on to start a VM; vm_delete requires it off first.

Returns: Dict with action (preview, noop, powered_off, still_running), blast_radius, and the executor's message under result.

Inputs: vm_name (required), force, target, confirm.

vm_power_onA
Idempotent

[WRITE] Power on a virtual machine.

Returns a status string; an already-on VM is a no-op. Reverse with vm_power_off. Call this first when a VM is off: guest tools such as vm_guest_exec only work once VMware Tools has finished booting.

Inputs: vm_name (required), target. Returns: result

vm_reconfigureA

[WRITE] Change a VM's vCPU count and/or memory.

Pass only the fields you want to change; omitted fields are left untouched. Hot-add of CPU/memory requires it to be enabled on the VM and a running guest; otherwise power the VM off first (vm_power_off).

Returns: Status string describing the applied change, or a VM-not-found error.

Inputs: vm_name (required), cpu, target, memory_mb. Returns: result

vm_revert_snapshotA
Destructive

[WRITE] Revert a VM to a named snapshot (loses changes since snapshot).

Without confirm=True this only previews: it returns blast_radius (VM and instance UUID, the snapshot's name, id and creation time, total snapshot count, current power state and the power state after the revert) and changes nothing. Show it to the user and get their decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Irreversible — everything written since the snapshot is lost. Refused: a snapshot name that is not found, a name that matches more than one snapshot on the VM (vSphere allows duplicates; rename one first), and a VM whose snapshot tree, identity or power state cannot be read. Run vm_list_snapshots first for exact names. To reclaim space without changing state use vm_delete_snapshot.

Returns: Dict with action (preview, reverted), blast_radius, and result.

Inputs: vm_name (required), snapshot_name (required), target, confirm.

vm_rollback_planA
Destructive

[WRITE] Rollback executed steps of a failed plan in reverse order.

Without confirm=True this only previews: it returns blast_radius listing the rollback steps that would run (in order, with the VMs a rollback deletes) and those skipped as irreversible — and runs nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet.

Only call this after vm_apply_plan returns status='failed'; check vm_list_plans first for the plan_id. Irreversible steps (delete_vm, revert_snapshot, etc.) are skipped with a warning. Each destructive rollback step (power off, delete snapshot, cluster delete, host removal) is measured as its own tool measures it, in the preview and again just before it runs; a refused check stops the rollback there and the plan stays 'failed'. Refused on a target other than the one the plan was created against.

Inputs: plan_id (required), target, confirm.

vm_set_ttlA
Destructive

[WRITE] Set a Time-To-Live (TTL) for a VM. The daemon auto-deletes it when expired.

Without confirm=True this only previews: it returns blast_radius — the VM that will be deleted (identity, host, disks, total size, snapshot count), when (expires_at), and any TTL it replaces — and schedules nothing. Show that to the user and get their explicit decision. Do not set confirm=True on your own because the user asked earlier: they have not seen the preview yet. Refused when the VM's identity or disks cannot be read.

Use this for short-lived lab VMs so cleanup is not forgotten; cancel with vm_cancel_ttl and review pending expiries with vm_list_ttl. The scheduler daemon must be running (vmware-knight daemon start) or nothing is ever deleted; it powers a running VM off first. TTLs persist in ~/.vmware-knight/ttl.json. Returns a dict (action, blast_radius).

Inputs: minutes (required), vm_name (required), target, confirm.

vm_task_statusA
Read-onlyIdempotent

[READ] Poll a long-running vSphere task by its id (from an async vm_delete_snapshot).

Use after vm_delete_snapshot returns a task id, instead of re-running the delete. Returns state (queued/running/success/error/gone), progress percent, and the entity name. 'gone' means vCenter already garbage-collected a completed task — re-list the resource to confirm the final state. A failed task reports its fault under 'task_error'; a top-level 'error' key would mean this poll itself failed.

Returns: Dict with task_id, state, progress_pct, operation, entity, and task_error/note when relevant.

Inputs: task_id (required), target.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

Loading tool schema changelog…

    TDQS

    A4.3/5.0

    Scored across 60 tools

    Disambiguation5/5

    Each tool has a clearly distinct purpose, with descriptions that explicitly differentiate similar operations (e.g., deploy_vm_from_ova vs. deploy_vm_from_template vs. vm_clone). Even closely related tools like vm_guest_exec and vm_guest_exec_output are clearly separated by their output-capturing behavior.

    Naming Consistency5/5

    All tool names follow a consistent verb_noun snake_case pattern (e.g., list_vcenter_alarms, create_drs_rule, vm_power_on, vm_guest_upload). The naming is uniform and predictable across all 60 tools.

    Tool Count3/5

    60 tools is high, but the server covers an extensive domain: VM lifecycle, snapshots, cloning, guest operations, cluster management, DRS rules, networking, datastore browsing, monitoring, TTL, and a plan system. Each tool has a specific role, so the count is defensible, though it may feel heavy for simple use cases.

    Completeness4/5

    The tool set provides comprehensive coverage of vSphere operations, including CRUD for VMs, snapshots, cloning, guest execution, cluster and DRS management, network portgroups and VMKs, datastore browsing, and monitoring bundles. Minor gaps exist (e.g., no explicit VM rename or vCenter host addition), but they do not block core workflows.

    Maintenance

    ActivitySlowing
    ResponsivenessNo recent community issues

    Related MCP Connectors

    Related MCP Servers

    • A
      license
      A
      quality
      A
      maintenance
      AI-powered VMware vCenter/ESXi monitoring and operations. 20 MCP tools for inventory queries, health monitoring, VM lifecycle management, fast provisioning (Linked Clone, OVA, template deploy), snapshot management, and datastore browsing. Supports vSphere 6.5–8.0. Works with local models via Ollama/LM Studio.
      44
      924 PyPI
      87
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables natural language interaction with VMware SDDC Manager and vCenter APIs through MCP tools, allowing users to query workload domains, VMs, clusters, and more.
      MIT
    • A
      license
      Not graded
      quality
      C
      maintenance
      Enables VMware vCenter management via MCP, adding real-time and historical performance monitoring, VM lifecycle operations, snapshots, ISO mounting, and network/host management through natural language.
      MIT