Skip to main content
A VM’s disks are Kubernetes volumes. The Disks tab on the VM detail page is where you add them, mount them, and take them away again — and where the difference between the four removal operations matters most.

​
Permissions

​
Disks defined at creation

Two kinds are set up when the VM is created — see Create a VM:
  • Root partitions carved out of the boot disk after the image’s own root partition, each with a mount path, size, and filesystem.
  • Data disks, blank disks formatted and mounted at a path you choose, each optionally on its own storage class.

​
Attaching a volume later

Attaching goes through KubeVirt’s add-volume subresource, which means one operation covers both states: on a running VM the disk is hot-plugged live; on a stopped VM it is written into the VM’s spec so it appears at next boot. Three sources:
Attach a PersistentVolumeClaim that already exists in the namespace. Use this to move a disk between VMs or to attach storage provisioned elsewhere.
The volume is attached to the VM, not mounted in the guest. A Linux guest still needs a filesystem and a mount — blank disks created at VM-creation time are formatted and mounted for you, but one attached later is a raw block device until you handle it.

​
Removing a volume — four different things

These are easy to confuse and only one of them destroys data.
Delete is irreversible. Everything on the volume is gone. Detach is the non-destructive inverse of attach — reach for that unless you specifically want the storage reclaimed.
Eject restarts the VM. It changes the VM’s spec rather than hot-unplugging, so it is not a live operation — expect downtime.
The best-effort guest unmount that precedes detach and delete needs the guest agent, and works on Linux guests only. On Windows, or with the agent down, the disk is pulled without the guest releasing its filesystem first — unmount it from inside the guest beforehand.

​
Storage class and volume mode

When a disk is created, Celum checks whether the target storage class can back a block volume and picks the volume mode accordingly. On file-based storage such as NFS, ReadWriteMany disks stay filesystem-mode so they bind at all — and matching the golden image’s mode is also what allows the fast clone path. This is why the storage class you choose has consequences beyond capacity:

​
Snapshots

VM snapshots capture all of a VM’s volumes at once and are managed from the Disks tab. They are on-demand only — nothing schedules or prunes them. Restoring rolls the whole VM back; to recover a single file, clone the snapshot into a new claim and attach it to a running VM instead. See VM lifecycle for the snapshot and restore flow.

​
Seeing usage from inside the guest

With the guest agent connected, the VM’s Resources tab shows per-filesystem used and total bytes as the guest reports them. This is the guest’s own view, so it accounts for what is actually mounted — unlike the claim sizes, which only tell you what was provisioned. The section is hidden when the agent is not connected.

​
Ephemeral VMs

A VM created with ephemeral boot writes to a copy-on-write overlay over a shared read-only golden.
Everything written to an ephemeral VM’s root disk is discarded when it stops — including on a restart. Attach a separate volume for anything that must survive.

​
What commonly goes wrong

Create a VM

Root partitions, data disks, and the access mode that decides migratability.

VM lifecycle

Snapshots, restore, and what deletion takes with it.

Console & access

Getting into the guest to format and mount a new disk.

Permissions

vm:AttachVolume and vm:Eject in the full action list.