Skip to main content
Every lifecycle operation is a separate permission, so you can grant an operator the power to restart a VM without the power to delete it. All of them are scoped to the individual VM: krn:celum:supervisor:<supervisor>:vm:<vm>. The Workloads page — tenant clusters and standalone VMs in one list with live state

​
Permissions at a glance

​
VMs Celum does not own

Not every VM on a supervisor was created by you. VMs provisioned by Cluster API as nodes of a guest cluster are managed — their lifecycle belongs to the controller that created them.
Start, stop, restart, delete, and edit are rejected with 409 on a managed VM. This is deliberate: stopping a cluster node behind its controller’s back would orphan the machine object. To remove such a VM, scale or delete the cluster that owns it.
The VM list distinguishes them, and shows the owning cluster and the node’s role (control plane or worker).

​
Power operations

1

Stop

Sets the VM’s runStrategy to Halted. A graceful shutdown when qemu-guest-agent is connected; without the agent the guest gets no clean shutdown signal.Result: the VM reports Stopped and its VirtualMachineInstance is gone. The VM object stays, which is why a stopped VM keeps its name, its disks and its address.
2

Start

Sets runStrategy to Always. An ephemeral VM starts from the golden every time — everything written during the previous run is gone.Result: a new instance is scheduled and the VM reaches Running.
3

Restart

Deletes the running instance and lets KubeVirt’s controller recreate it. Required to pick up a new instance type.Result: the VM comes back on a fresh instance — provided its runStrategy is Always.
Restarting a stopped VM does nothing. Restart deletes the instance and the controller recreates it according to runStrategy — and a stopped VM is Halted, so nothing comes back. There is no error: the call succeeds and the VM stays down. Start it instead.

​
Resizing

Changing a VM’s instance type changes its CPU and memory allocation. The change is recorded immediately but takes effect at the next start or restart — KubeVirt resolves the instance type into the running instance only at boot. The response says so explicitly, and the previously pinned revision is cleared so the new class is picked up rather than the old snapshot of it.
A VM that appears unchanged after a resize has almost certainly not been restarted yet.

​
Catalog labels

Catalog labels are key=value tags that Celum keeps on a VM, so that you can filter and group VMs in Workloads. Celum stores them as one annotation, nuvira.dev/labels, on the VirtualMachine. They are not Kubernetes labels, so network policies, Cilium selectors and the VM’s pod do not see them.
On the VM’s Resources tab, Edit on the Catalog labels card opens Edit catalog labels. Add label adds a row, and the bin removes one. Save labels replaces the whole set. Every row needs a key, and the keys must be unique.
The labels you set on the create form are the same labels.

​
Live migration

Migration moves a running VM to another node without stopping it.
Bringing a VM in from VMware vCenter is a different operation, done with Forklift: see Migrate VMs from vSphere.
Prerequisite: the VM must be migratable. Celum reports that as migratable, derived from the VM’s eviction strategy — LiveMigrate means yes. Two create-time choices put a VM on the wrong side of it: a ReadWriteOnce image, whose disk cannot be attached on two nodes at once, and networkMode: bridge, which clears the eviction strategy on purpose so an unmigratable VM cannot wedge a node drain. masquerade and passt both migrate.
migratable is about the VM, not about its storage. KubeVirt reports it from the access mode and the eviction strategy, and it can say yes over a disk the storage backend will refuse to attach twice. The migration then stays Scheduling with the target pod in Init, and the reason appears on that pod rather than on the VM. On LINSTOR’s shared array pool this needs a driver, a class parameter and a matching golden — see the requirements.
By default the scheduler picks the destination. You can pin a target node — useful when draining one — and the target is validated against the real node list first, because an invalid node selector does not fail loudly: KubeVirt fills the namespace with pod warnings while the migration never starts. Result: the migration object is created and the VM moves. That the VM is Running on a new host is a weak check — a restart looks the same. The real proof is that a connection open before the move is still the same connection after it.
A stuck migration blocks every future one. KubeVirt refuses a new migration while one is outstanding — “in-flight migration detected” — so a migration pinned to a node that can never take it makes the VM permanently unmovable. Cancelling removes exactly the unfinished migrations for that VM, which is the repair. If a VM refuses to migrate and nothing looks wrong, check for a leftover migration before anything else.
A VM with the identity network keeps its identity address across the cutover. That is what the identity network exists for — the pod IP does not survive.

​
Snapshots

Snapshots capture a point-in-time copy of all of a VM’s volumes, and a restore rolls the VM back to one.
Snapshots are on-demand only. There is no scheduler and no retention policy — nothing takes them for you, and nothing prunes them. If you need periodic snapshots, drive them from outside Celum.
With the guest agent connected, the filesystem can be frozen for the snapshot, which is what makes it consistent. Without the agent, you get a crash-consistent copy.

​
Take a snapshot

On the VM’s Disks tab, Take snapshot opens Take VM snapshot with a name already filled in: <vm>-snapshot-<YYYYMMDD>-<HHMM>, in your browser’s local time. Change it to a name you will recognise, for example before-upgrade, then choose Create snapshot. The VM can keep running. The list refreshes every 15 seconds, and the snapshot is ready when it reaches Succeeded.
  • The name becomes the name of a VirtualMachineSnapshot object in the VM’s namespace. It must therefore be a valid Kubernetes object name (lowercase letters, digits, - and .) and unique among the snapshots in that namespace. Kubernetes refuses any other name, and Celum passes on its message.
  • A supervisor without KubeVirt’s snapshot API returns 501.
  • Restore needs the VM stopped. Celum refuses a running VM with 409. A restore rolls back all of the VM’s volumes, and every change since the snapshot is lost.

​
Clone and move between projects

Kubernetes has no in-place namespace move, so both operations work by copying:
1

Disks are cloned

The VM’s disks are cloned into the target namespace.
2

The VM is recreated

The VM is rebuilt there, along with its provisioning secrets and config maps.
3

It is verified running

The copy must come up before the operation is considered successful.
4

For a move, the source is removed

A move then stops and deletes the original. A clone leaves it in place and names the copy <vm>-copy unless you choose a name.
Result: the copy is Running in the target namespace. Check that before you rely on a move having completed — the original is only removed once the copy comes up, so a half-finished move leaves you with the source still there rather than with nothing.
Exposures are not carried over. LoadBalancer services, gateway publications, and their routes stay behind — the copy lands unexposed and you re-publish it in the new project. See Networking.
Because the target is a different project namespace, the VM also picks up that project’s isolation policy and address space rather than the one it left.

​
Deleting

Deleting a VM removes the VM object. Disks that were created as part of it go with it; volumes you attached from existing claims are a separate decision — see Storage & disks.
There is no undo and no recycle bin. If the VM held data you care about, take a snapshot first — and note that deleting the VM does not preserve snapshots as a restore path for a VM that no longer exists.

​
Diagnosing a stuck VM

The VM detail page carries an Events tab, which surfaces the Kubernetes events for that VM. When a VM will not start, that is the first place to look — scheduling failures, image pull problems, and PVC binding issues all report there with the underlying reason.

Create a VM

The choices made at creation that constrain lifecycle later.

Storage & disks

Volumes, snapshots, and what deletion takes with it.

Networking

What a move leaves behind and how to re-publish.

Permissions

Every vm:* action and its KRN.

Migrate VMs from vSphere

Bring VMs in from vCenter, cold or warm, keeping their addresses.