VMware VKS

VMware VKS

For a read-only check of this skill with your model and agent host, use the shared model-fit self-test in the marketplace root.

Author: Wei Zhou, VMware by Broadcom — [email protected] 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 | 中文

MCP Skill + CLI for VMware vSphere Kubernetes Service (VKS) management — Supervisor clusters, vSphere Namespaces, and VKS Cluster lifecycle. 25 MCP tools.

[License: MIT]

Upgrading to 3.0

3.0 renames the two kubeconfig tools: get_supervisor_kubeconfig → issue_supervisor_kubeconfig, get_tkc_kubeconfig → issue_tkc_kubeconfig. They issue a credential (a Supervisor bearer token) rather than read something, and a get_ name told agents otherwise. Parameters, annotations, safety and CLI commands (vmware-vks kubeconfig supervisor / kubeconfig get) are unchanged; callers of the old names must switch (saved vmware-pilot workflows are translated by Pilot ≥ 2.0.0). Deny rules in ~/.vmware/rules.yaml naming the old names keep working with vmware-policy ≥ 1.19.0. Details in RELEASE_NOTES.md.

Upgrading to 2.0

2.0 renames the three VM Service tools: list_vm_snapshots → list_vm_service_snapshots, list_vm_groups → list_vm_service_groups, list_vm_network_interfaces → list_vm_service_network_interfaces. The reason is a name clash: in the family's 2.0, vmware-aiops and vmware-monitor call their vSphere VM snapshot tool list_vm_snapshots, while these list Kubernetes VM Service (vm-operator) objects. Trap: an agent prompt, script or saved workflow that still calls list_vm_snapshots with vmware-aiops or vmware-monitor also loaded now reaches the vSphere tool, not this one — update it. A VKS-scoped deny rule naming list_vm_snapshots now also matches the aiops/monitor tool (vmware-policy ≥ 1.18 matches both names; vmware-audit policy lists such rules). Parameters, safety gates and CLI commands are unchanged; the full table is in RELEASE_NOTES.md. If an install older than 2.0 shares that rules.yaml, give it vmware-policy ≥ 1.18.2 too: it matches each rule against both the old and the new name, so one file serves both.

Companion Skills

Part of the VMware MCP Skills family. Each skill handles a distinct domain — install only what you need.

Prerequisites

• Python 3.10+ — required for uv tool install
• vSphere 8.0+ — Workload Management (Supervisor) APIs require vSphere 8.x
• Workload Management enabled — WCP must be enabled on at least one compute cluster
• License — vSphere Kubernetes Service (Enterprise Plus or VMware Cloud Foundation)

Run vmware-vks check after setup to verify all requirements are met.

Quick Start

# Installuv tool install vmware-vks
# Configuremkdir -p ~/.vmware-vkscp config.example.yaml ~/.vmware-vks/config.yaml# Edit config.yaml with your vCenter host and username
# One password env var per target, named after the target in config.yaml:# target "vcenter01" (the one config.example.yaml ships) -> VMWARE_VKS_VCENTER01_PASSWORDecho "VMWARE_VKS_VCENTER01_PASSWORD=your_password" > ~/.vmware-vks/.envchmod 600 ~/.vmware-vks/.env
# Verifyvmware-vks check
# Common operationsvmware-vks supervisor status domain-c1vmware-vks namespace listvmware-vks tkc listvmware-vks tkc create my-cluster -n dev --version v1.28.4+vmware.1 --vm-class best-effort-largevmware-vks tkc create my-cluster -n dev --apply

Offline / Air-Gapped Install (from source)

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:

# From the source tree — a normal (non-editable) install builds a wheel:pip install .              # NOT  pip install -e .
# ...or upgrade pip first, and editable works too:pip install --upgrade pip && pip install -e .

For a truly air-gapped host, build the wheels on a connected machine and copy them over — the target then needs no network:

# On a connected machine, collect this package + its dependencies as wheels:pip wheel . -w dist        # → dist/*.whl   (or: uv build, for just this package)
# Copy dist/ to the air-gapped host, then install offline:pip install --no-index --find-links dist vmware-vks

Common Workflows

Deploy a New TKC Cluster

1. Check compatibility → vmware-vks check
2. List available K8s versions → vmware-vks tkc versions -n dev
3. Create namespace (if needed) → vmware-vks namespace create dev --cluster domain-c1 --storage-policy <policy-id> --cpu 16000 --memory 32768 --apply (get the policy ID from vmware-vks supervisor storage-policies)
4. Create TKC cluster → vmware-vks tkc create dev-cluster -n dev --version v1.28.4+vmware.1 --control-plane 1 --workers 3 --vm-class best-effort-large --apply
5. Get kubeconfig (credential; only when you need cluster access) → vmware-vks kubeconfig get dev-cluster -n dev -o ./kubeconfig — writes an owner-only file instead of printing the token

Scale Workers for Load Testing

1. Check current state → vmware-vks tkc get dev-cluster -n dev
2. Scale up → vmware-vks tkc scale dev-cluster -n dev --workers 6
3. Monitor progress → vmware-vks tkc get dev-cluster -n dev (watch phase)
4. Scale back down after test

Namespace Resource Management

1. List namespaces → vmware-vks namespace list
2. Check usage → vmware-vks storage -n dev
3. Update quota → vmware-vks namespace update dev --cpu 32000 --memory 65536

Tool Reference (25 tools)

Supervisor

For an upgrade from vCenter 8.0 Update 3 or 9.0.0–9.0.2 to 9.1.0/9.1.1, run supervisor upgrade-risk before scheduling. Its report cannot inspect the VUMDB schema or establish upgrade clearance. If a Supervisor/VKS environment is in scope, follow the Broadcom checker and remediation instructions or VDT, then back up vCenter and Supervisor before upgrading.

Namespace

TKC

Access

VCF 9.1 TKC access: In one live 9.1 report, issue_tkc_kubeconfig put a Supervisor JWT into the guest kubeconfig and the TKC API rejected it with 401. Treat the generated file as unverified for guest access; test it against the guest API before use. See issue #27. Supervisor-scoped TKC reads are unaffected in that report.

VM Service (vm-operator)

Permissions

Architecture

User (Natural Language)  ↓AI Agent (Claude Code / Goose / Cursor)  ↓ reads SKILL.md  ↓vmware-vks CLI  ─── or ───  vmware-vks MCP Server (stdio)  │  ├─ Layer 1: pyVmomi (/sdk) + vSphere Automation REST (/api)  │   Supervisor status, storage policies, Namespace CRUD, VM classes, Harbor  │   Two session stores: the SOAP session from SmartConnect, and a separate  │     REST session id from POST /api/session (vmware-api-session-id header)  │  └─ Layer 2: kubernetes client → Supervisor K8s API endpoint      TKC CR apply / get / delete  (cluster.x-k8s.io API version auto-detected:        prefers v1 when Supervisor serves it, falls back to v1beta1 for vSphere 8.0)      Kubeconfig built in-memory from the POST /wcp/login bearer token        (a third credential, and no temp file on disk)  ↓vCenter Server 8.x+ (Workload Management enabled)  ↓Supervisor Cluster → vSphere Namespaces → TanzuKubernetesCluster

CLI Reference

# Pre-flight diagnosticsvmware-vks check
# Supervisorvmware-vks supervisor status <cluster-id>vmware-vks supervisor upgrade-risk --to 9.1.1vmware-vks supervisor storage-policies
# Namespacevmware-vks namespace listvmware-vks namespace get <name>vmware-vks namespace create <name> --cluster <id> --storage-policy <policy>vmware-vks namespace create <name> --cluster <id> --storage-policy <policy> --applyvmware-vks namespace update <name> [--cpu <mhz>] [--memory <mib>]vmware-vks namespace delete <name>vmware-vks namespace vm-classes
# VKS Clustervmware-vks tkc list [-n <namespace>]vmware-vks tkc get <name> -n <namespace>vmware-vks tkc versions -n <namespace>vmware-vks tkc create <name> -n <namespace> [--version <v>] [--vm-class <c>]vmware-vks tkc create <name> -n <namespace> --applyvmware-vks tkc scale <name> -n <namespace> --workers <n>vmware-vks tkc upgrade <name> -n <namespace> --version <v>vmware-vks tkc delete <name> -n <namespace>
# Kubeconfigvmware-vks kubeconfig supervisor -n <namespace> [-o <path>]vmware-vks kubeconfig get <cluster-name> -n <namespace> [-o <path>]
# Harbor & Storagevmware-vks harborvmware-vks storage -n <namespace>

MCP Server

After uv tool install vmware-vks, start the MCP server with one command (v1.5.15+):

# Recommended — single command, no network re-resolvevmware-vks mcp
# With a custom config pathVMWARE_VKS_CONFIG=/path/to/config.yaml vmware-vks mcp

Agent Configuration

Add to your AI agent's MCP config:

{  "mcpServers": {    "vmware-vks": {      "command": "vmware-vks",      "args": ["mcp"],      "env": {        "VMWARE_VKS_CONFIG": "~/.vmware-vks/config.yaml"      }    }  }}

# Run without installing (requires PyPI access each launch)uvx --from vmware-vks vmware-vks mcp
# Legacy entry point (still works, kept for backward compatibility)vmware-vks-mcp

Safety

Troubleshooting

"VKS not compatible" error

Workload Management must be enabled in vCenter. Check: vCenter UI -> Workload Management. Requires vSphere 8.x+ with Enterprise Plus or VCF license.

Every command fails with "session is not authenticated"

The password is right. Either the session expired (run the command again; a new session is opened) or the account has no vSphere role, so vCenter shows no session for it and every call fails. VKS does not refuse such a login when it connects, because an account holding only Supervisor namespace permissions can look the same and still work; the error appears on the first call that needs a role. Assign the account a role (Read-Only or higher) on the vCenter root folder under Administration > Access Control > Global Permissions; Namespace and TKC work also needs Workload Management privileges.

Every REST tool returns 401

The namespace, storage-policy and Supervisor-status tools authenticate against the vSphere Automation REST API with a session id from POST /api/session — not the pyVmomi SOAP session key, which that API never issued and always rejects. A 401 is refreshed automatically once; if it persists, check whether a proxy between you and vCenter strips the vmware-api-session-id header. An account short of Workload Management permissions gets a 403, not a 401.

Namespace creation fails with "storage policy not found"

List policies first: vmware-vks supervisor storage-policies, then pass the Policy ID column value (not the display name) as --storage-policy.

TKC cluster stuck in "Creating" phase

Check Supervisor events in vCenter. Common causes: insufficient resources on ESXi hosts, network issues with NSX-T, or storage policy not available on target datastore.

Kubeconfig retrieval fails

Supervisor API endpoint must be reachable from the machine running vmware-vks. Check firewall rules for port 6443.

Scale operation has no effect

Verify the cluster is in "Running" phase before scaling. Clusters in "Creating" or "Updating" phase reject scale operations.

Delete namespace rejected unexpectedly

The namespace delete guard prevents deletion when TKC clusters exist inside. Delete all TKC clusters in the namespace first, then retry.

Version Compatibility

Official Broadcom References

• SDKs: https://developer.broadcom.com/sdks — VCF Python SDK (unified SDK in VCF 9+)
• REST APIs: https://developer.broadcom.com/xapis — vSphere Automation API (Workload Management endpoints)
• CLI Tools: https://developer.broadcom.com/tools — kubectl-vsphere, PowerCLI 9.1

Related Projects

Remote access (HTTPS) and limiting tools

By default vmware-vks mcp speaks stdio to one local client and offers every tool. Two options change that (vmware-policy ≥ 1.21.0).

Serve over HTTPS so clients on other machines can connect. Every caller needs a bearer token:

vmware-audit token create alice          # prints the token once; give it to alicevmware-audit token list                  # names onlyvmware-audit token revoke alice          # refused from its next request, no restartvmware-vks mcp --transport https --host 0.0.0.0 --port 8443 \    --cert /etc/vmware-mcp/server.pem --key /etc/vmware-mcp/server-key.pem \    --public-name mcp.example.com

Connect a client (Claude Code shown; any MCP client that supports streamable HTTP and custom headers works):

claude mcp add --transport http vmware-vks https://mcp.example.com:8443/mcp \    --header "Authorization: Bearer $VMWARE_MCP_TOKEN"

{  "mcpServers": {    "vmware-vks": {      "type": "http",      "url": "https://mcp.example.com:8443/mcp",      "headers": { "Authorization": "Bearer ${VMWARE_MCP_TOKEN}" }    }  }}

• The server will not start without a token, refuses Host/Origin values outside --public-name, and checks before it binds that unauthenticated requests get 401. Use a certificate your clients trust for those names.
• Behind a TLS-terminating reverse proxy on the same machine use --transport http --host 127.0.0.1 --public-name mcp.example.com and pass the Authorization header through.
• Behind a load balancer or gateway on another machine, keep --transport https (a self-signed certificate is fine), list in --public-name the host name the balancer sends as Host, and have it forward Authorization. Its health probe can use GET /healthz, which needs no token and returns only {"status": "ok"} (vmware-policy ≥ 1.23.0).
• Send traceparent or X-Request-ID with each request to have it stored on the audit row; vmware-audit log --correlation-id ID then finds the calls behind one platform request.
• Tools that read or write files on this server (here: issue_*_kubeconfig(output_path)) never touch its configuration, tokens, audit log or TLS key, and over the network they are off unless VMWARE_MCP_FILE_ROOT names a directory for them (vmware-policy ≥ 1.23.1).
• The audit log records each caller as token:<name>. Calls run side by side, also on the same target: the server keeps up to VMWARE_MCP_POOL_SIZE (default 2) sessions per target, each one a login on that target, and a call waits at most 300 s for a free session (vmware-policy ≥ 1.22.0).
• Everyone who can reach the endpoint acts with this server's account. Tokens identify callers; they grant nothing on the platform. Run one endpoint per privilege level. vmware-vks access-info shows which account that is and what it may do.
• Several people or roles on one endpoint: run vmware-audit roles enable once, then give each token a role (vmware-audit token create NAME --role reader, or a role in roles.yaml naming tools and targets; vmware-policy ≥ 1.24.0). A role limits what the token may call on this endpoint; it cannot grant more than the account has. See vmware-policy's README, "Roles for network callers".

Offer only read tools, plus the writes you choose:

vmware-vks mcp --expose read --allow-write create_namespace# or: VMWARE_VKS_MCP_EXPOSE=read VMWARE_VKS_MCP_ALLOW_WRITE=create_namespace vmware-vks mcp

Tools not offered do not appear in the client's tool list. A bad value or an unknown write tool stops the server (exit 2). This limits what clients are offered; it is not authorization, so the account itself should be least-privilege.

Details: skills/vmware-vks/references/setup-guide.md ("Serving MCP over HTTPS", "Limiting which tools are offered").

License

MIT