Bringing KubeVirt guest consoles to AI agents

Kubernetes can report that a virtual machine is running even when its guest operating system has crashed with a kernel panic.

It can show the VirtualMachineInstance (VMI), its events, and the virt-launcher pod that hosts the VM process, but it may still not show what is on the guest's screen.

A person troubleshooting the VM would open its graphical or serial console and see the problem immediately.

I built KubeVirt Console MCP to give AI agents that same view.

The missing view

KubeVirt adds APIs to Kubernetes for running and managing virtual machines. Those APIs describe the VM and its surrounding infrastructure, but they do not always show whether the guest reached a usable state.

The Kubernetes MCP Server already gives agents structured access to cluster resources, status, events, logs, and KubeVirt operations. I wrote about that broader work in Giving AI agents Kubernetes and KubeVirt tools.

That view covers much of the troubleshooting process. Missing evidence may appear only at the guest console: BIOS or UEFI screens, bootloaders, installers, recovery prompts, login screens, or early failures before a guest agent or SSH is available.

KubeVirt already exposes graphical and serial consoles for people. This MCP server makes evidence from those consoles available to AI agents.

Three forms

The server exposes three focused tools:

• console_screenshot captures the current graphical screen through KubeVirt's VNC screenshot API and returns a PNG image.
• console_log reads available guest serial output from the guest-console-log sidecar's Kubernetes pod logs.
• console_capture reads new output from the live serial console for a short time without sending input.

I kept them separate because each answers a different question. A screenshot shows what the guest displays now, the log can show earlier boot messages, and a live capture collects new output.

If the live connection opens but no output arrives, console_capture reports a quiet guest rather than a connection failure.

Exposing the consoles through MCP

I deliberately kept the server small. It uses the official MCP Go SDK and exposes only these three console tools.

MCP lets compatible agents call named tools with clear inputs instead of building KubeVirt API requests or shell commands themselves.

The server returns console evidence without diagnosing the VM or deciding what to do next. The model can interpret it alongside data from Kubernetes MCP Server.

Kubernetes reports a running VM; the guest console reveals that it has stopped at a kernel panic.

Keeping console access constrained

Console access is sensitive. Screenshots and serial logs can contain hostnames, IP addresses, application output, and credentials.

• KubeVirt authorizes console access separately, so permission to inspect a VMI does not automatically grant access to its console.
• The MCP server returns console contents to AI agents without storing them or including them in application logs.
• The live serial console tool is read-only and never sends input to the guest, so it cannot execute commands or enter credentials.

Current limitations

Screenshots require a running VMI with graphics enabled. The serial tools require an attached console, and they provide output only when the guest writes to it.

The console_log also requires KubeVirt serial-console logging. Its history comes from Kubernetes pod logs rather than durable storage, so deleting or replacing the virt-launcher pod can make earlier output unavailable.

Opening console_capture replaces any existing serial-console connection to the VMI. If another client connects later, it can end the capture.

Toward upstream integration

KubeVirt Console MCP is a separate project, and its console tools are not part of the official Kubernetes MCP Server — The next step is to propose bringing these console capabilities there rather than maintaining them as a separate MCP server.

The OpenShift MCP Server is built on Kubernetes MCP Server. OpenShift includes the MCP server as a Technology Preview, with the optional kubevirt toolset available.

Bringing both views together

Giving AI agents access to both closes an important gap. An agent can first inspect the Kubernetes state and, when that is not enough, look at the same console evidence a person would use.

Kubernetes tells the agent that a VM is running. The console lets it verify what the guest is actually doing before suggesting a solution.