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
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:
For a truly air-gapped host, build the wheels on a connected machine and copy
them over — the target then needs no network:
Common Workflows
Deploy a New TKC Cluster
- Check compatibility →
vmware-vks check
- List available K8s versions →
vmware-vks tkc versions -n dev
- 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)
- 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
- 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
- Check current state →
vmware-vks tkc get dev-cluster -n dev
- Scale up →
vmware-vks tkc scale dev-cluster -n dev --workers 6
- Monitor progress →
vmware-vks tkc get dev-cluster -n dev (watch phase)
- Scale back down after test
Namespace Resource Management
- List namespaces →
vmware-vks namespace list
- Check usage →
vmware-vks storage -n dev
- 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
get_tkc_cluster.worker_pools lists every declared worker pool. worker_replica_total
is the sum only when every pool has a known fixed replica count; it is null
for an autoscaled or unreadable pool. The older worker_replicas field remains
the first pool only for compatibility and must not be interpreted as the
cluster total.
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
CLI Reference
MCP Server
After uv tool install vmware-vks, start the MCP server with one command (v1.5.15+):
Agent Configuration
Add to your AI agent's MCP config:
Alternative: uvx (no install) or legacy entry point
Behind a corporate TLS proxy? uvx may fail with invalid peer certificate: UnknownIssuer.
Use the recommended vmware-vks mcp form above (no network needed), or set UV_NATIVE_TLS=true.
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
VKS 3.8 introduces vendor-managed chained upgrades and more granular node
placement (official announcement).
This skill's upgrade_tkc_cluster still submits one requested Kubernetes version;
it does not verify or orchestrate the 3.8 upgrade chain or placement policy.
The new worker-pool summary is a read of the existing Cluster topology, not a
VCF 9.1/VKS 3.8 compatibility claim. Live 9.1/3.8 validation is pending.
Official Broadcom References
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:
Connect a client (Claude Code shown; any MCP client that supports streamable HTTP and custom headers works):
- 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:
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