Skip to main content
There are two ways into a VM: the graphical console, which always works while the VM is running, and the guest agent, which unlocks everything else Celum can tell you about the inside of a guest.

​
The console

The VM detail page has a Console tab that proxies KubeVirt’s VNC connection to your browser. It needs no agent, no network publication, and no credentials inside the guest beyond what you would type at a physical screen — which makes it the right tool when a VM has no address, no route, or a broken network configuration. The tab is available only while the VM is running.
vm:VncProxy grants interactive keyboard and screen access to the running guest, with no further authentication in front of it. Anyone holding it can act as whoever is logged in at the console. Treat it as a privileged grant — it is in K8sGateOperator but deliberately not in K8sGateViewer.

​
Credentials

Guest credentials are set when the VM is created and are not managed by Celum afterwards:
WinRM is never published through a LoadBalancer. It is reachable on the VM’s own address only — from inside the cluster, or over an identity address.
To reach SSH or RDP from outside, publish the port — see Networking. The console does not require that.

​
The guest agent

qemu-guest-agent runs inside the guest and is installed by default on Linux disk images. Its connection state is reported on the VM, and it is the prerequisite for a surprising amount of the product:
The agent is reported as disconnected for a stopped VM, because there is no running instance to connect. Check the VM’s power state before concluding the agent is missing.

​
Introspection

With the agent connected, Celum can look inside the guest. All of these are reads gated by vm:Get.
One entry per listening socket — port, protocol, and the process holding it — with an advisory flag for sockets bound only to localhost. This is the view to consult before publishing a port.
The guest’s top processes by CPU. Linux guests only — Windows returns 404 and the UI shows a placeholder instead.
Per-filesystem used and total bytes as the guest reports them, on the Resources tab. Hidden when the agent is not connected.
Four probes run inside the guest — default gateway, cluster DNS, public internet, and the VM’s own LoadBalancer address. See Networking.
The guest agent runs as root inside the VM, so these endpoints see everything. The commands are fixed server-side — an operator never supplies any part of them — but vm:Get still means “can read the process list and open sockets of this VM”. Scope it accordingly.

​
Metrics

The Resources tab renders CPU, memory, network, and disk trends from KubeVirt’s own metrics, read from the supervisor’s Prometheus. They require the monitoring stack to be installed on that supervisor; without it the tiles have no data. Unlike the introspection endpoints, metrics come from the hypervisor rather than from inside the guest, so they work with or without the agent.

​
Logs

Two independent paths, and knowing which one you have determines what you can search for: Both land in the same Grafana as pod logs, labelled with the VM name, so a boot failure and an application error are queryable side by side.
Serial console capture is why a VM that never finishes booting still has something to read. If the guest does not write to its serial port, there will be nothing there — standard cloud images do.
In-guest log shipping is chosen at creation time and applies to Linux cloud-init images. Turning it on also opens the egress path the in-guest agent needs, which is worth knowing if the VM’s project has observability egress switched off — see Projects.

​
Events

When the problem is that the VM will not start at all, none of the above applies — there is no guest yet. The Events tab carries the Kubernetes events for the VM, which is where scheduling failures, image problems, and unbound claims report their actual reason.

​
What commonly goes wrong

Create a VM

Guest agent, credentials, and log shipping are all creation-time choices.

Networking

Publishing SSH, RDP, and web ports.

VM lifecycle

Why graceful shutdown and consistent snapshots depend on the agent.

Permissions

vm:VncProxy and vm:Get in the full action list.