Files
Mattia Eleuteri b4f6fb67db fix(vm-disk): let CDI adopt the PVC a Velero restore recreates
A Velero restore of a VMDisk or a VMInstance deletes the disk's
DataVolume and restores the PVC under its name, with no owner. The
restored release is in sync, so nothing recreates the DataVolume until
the next Helm upgrade, typically a platform update. That upgrade is
refused by CDI's admission webhook ("Destination PVC ... already
exists") and the release stays failed, followed by the VMInstance
release that looks the disk up.

CDI admits a DataVolume over an existing claim only when the
DataVolume carries cdi.kubevirt.io/allowClaimAdoption or the
DataVolumeClaimAdoption feature gate is on. The restore controller
puts the annotation on the restored PVC, where CDI never reads it, and
the CDI CR does not enable the gate. Setting it on the DataVolume
keeps the scope to vm-disk instead of every DataVolume in the cluster,
and does not depend on a gate CDI intends to remove. A claim CDI
created for this DataVolume carries its uid in createdForDataVolume
and is never treated as adoptable, so a fresh import is unaffected.

The VMDisk backup round-trip now forces an upgrade after the restore,
which is what reaches the failure, and checks that the DataVolume
adopted the restored PVC instead of replacing it.

Signed-off-by: Mattia Eleuteri <mattia@hidora.io>
Assisted-by: LLM
2026-10-19 10:24:14 +02:00
..
2025-09-18 16:27:38 +02:00
2024-10-16 18:35:30 +02:00
2025-09-24 12:32:37 +02:00

Virtual Machine Disk

A Virtual Machine Disk

storageClass and source are annotated as immutable in the chart schema — see docs/storage-immutability.md for the contract and which consumers enforce it. DataVolume.spec is immutable in CDI, so the chart also fails the release on an attempted storageClass/source edit of an existing disk rather than silently reusing the old spec; delete and recreate the disk to change either field.

Whether CDI has finished populating the disk shows up in the WorkloadsReady condition, not in Ready, which follows the Helm release and does not wait on the DataVolume: WorkloadsReady stays False while an import, clone or upload is in flight and when the DataVolume fails. Its message names the DataVolume and the phase it is in, followed by the error CDI reports for the pod populating the disk when there is one, such as a 404 or an unresolvable host on an HTTP source: CDI keeps retrying such an import, so its phase stays ImportInProgress, and the error is shown between retries rather than while a retry is running. kubectl get vmdisks shows the condition in the WORKLOADS column, and the console badge reads DataVolumeNotReady until it is True. A disk created before this behaviour was introduced keeps its old release settings, under which Ready may wait on the DataVolume, until its application is next updated. A source.upload disk reads False from the moment it is created until virtctl image-upload completes, because CDI reports waiting for the upload and receiving it as one phase. A disk counts as ready while it waits for its consumer with bindImmediately off on a WaitForFirstConsumer class, because that is a state such a disk is supposed to rest in.

bindImmediately is on by default, so a disk's volume is provisioned when the disk is created rather than deferred to the first consumer. That default exists because a VMDisk is a standalone object with a lifecycle of its own: on a WaitForFirstConsumer StorageClass a disk that no VM has attached yet would otherwise never populate at all. It costs something on a node-pinned class such as local, where the CDI worker pod becomes the first consumer and the volume lands where that pod was scheduled rather than where the VM will run, so a VM whose placement is constrained (a nodeSelector, a resource request only one node satisfies, or the Windows affinity applied by _cluster.scheduling.dedicatedNodesForWindowsVMs) can stay unschedulable against a node-affinity conflict, and storageClass is immutable so the only exit is deleting and recreating the disk. Turn bindImmediately off for a disk a VMInstance will consume on such a class: KubeVirt then renders a temporary launcher pod carrying the VM's own affinity and node selector, and the volume binds where the VM can actually run. The chart default replicated binds Immediate regardless, so neither setting changes anything there.

A disk created from source.image should use the StorageClass its golden image lives in, replicated in the default layout. When CDI clones with the csi-clone strategy, the platform default, into a different StorageClass of the same CSI driver with the same volume mode and room to expand, it does not fall back to a host-assisted copy and leaves the clone to the driver. The snapshot strategy does the same when it gets a VolumeSnapshotClass of that driver: the class both StorageProfiles name, or, when they do not name the same one, any class of the driver. LINSTOR creates that clone next to the source data, so on a target class that does not allow remote volume access from every node, such as a node-local class, the clone may never bind. The chart refuses such a new disk when the golden's driver and the target class's provisioner are both LINSTOR and the target's allowRemoteVolumeAccess is not a value linstor-csi reads as true (1, t or true, in any of the cases Go's strconv.ParseBool accepts); any other value is a list of rules, and the chart counts it as access from anywhere only when one rule names no fromSame label. Without that parameter it reads the target's layer list the way linstor-csi does, which allows remote access when it has a DRBD or NVMe layer, and a class that sets no layer list has DRBD. Under snapshot, it also refuses a disk whose golden and target StorageProfiles name the same VolumeSnapshotClass when that class does not exist and the golden's driver is the target class's provisioner, whatever the driver: CDI then fails to plan the clone instead of falling back. Both refusals compare only what they can look up: without the golden image's PVC, the cdi resource or the target's StorageClass nothing is compared. The remote access refusal also needs the target's StorageProfile with a claim property set and the golden's driver, taken from its bound PV or else from its StorageClass; when any of them is missing, the disk renders. Neither applies to a disk whose DataVolume or PVC already exists. Use the golden image's StorageClass instead, or ask the platform administrator to set cloneStrategyOverride: copy in the kubevirt-cdi package, which clones through a host-assisted copy in every case. The remote access refusal leaves alone a target class that allows remote volume access, a driver other than LINSTOR, a target class of another driver, a different volume mode, a class without volume expansion, snapshot that gets no VolumeSnapshotClass of the driver, and the copy strategy. An empty storageClass is compared as the class CDI would pick for it: the class annotated storageclass.kubevirt.io/is-default-virt-class, otherwise the class annotated storageclass.kubernetes.io/is-default-class; when several classes carry the annotation that decides, nothing is compared.

Parameters

Common parameters

Name Description Type Value
source The source image location used to create a disk. object {}
source.image Use image by name from default collection. *object null
source.image.name Name of the image to use. string ""
source.upload Upload local image. *object null
source.http Download image from an HTTP source. *object null
source.http.url URL to download the image. string ""
source.disk Clone an existing vm-disk. *object null
source.disk.name Name of the vm-disk to clone. string ""
optical Defines if disk should be considered optical. bool false
storage The size of the disk allocated for the virtual machine. quantity 5Gi
storageClass StorageClass used to store the data. string replicated
bindImmediately Provision the volume at disk creation instead of waiting for a consumer. bool true