Myasnikov Daniil
a115745c69
Immediate binding for every source fixed a real bug: a standalone disk on a WaitForFirstConsumer class has no consumer to wait for, so it never populated. It also took away the path that is correct for the other case. For a disk a VMInstance consumes, KubeVirt renders a temporary launcher pod carrying the VM's own affinity and nodeSelector, so the volume binds where the VM can actually run; with the annotation always present the CDI worker becomes the first consumer instead and the volume lands where that pod happened to be scheduled. On a node-pinned class the VM is then unschedulable against a node-affinity conflict, and storageClass is immutable, so the only exit is deleting the disk. The two cases want opposite defaults and only the operator knows which one a given disk is. bindImmediately defaults to true, so nothing moves for existing disks or for anyone on `replicated`, which binds Immediate either way. Both branches are pinned in tests, including the existing-DataVolume path, which renders its own annotation block. Signed-off-by: Myasnikov Daniil <myasnikovdaniil2001@gmail.com> Assisted-By: LLM
Virtual Machine Disk
A Virtual Machine Disk
storageClassandsourceare annotated as immutable in the chart schema — seedocs/storage-immutability.mdfor the contract and which consumers enforce it.DataVolume.specis immutable in CDI, so the chart also fails the release on an attemptedstorageClass/sourceedit of an existing disk rather than silently reusing the old spec; delete and recreate the disk to change either field.
bindImmediatelyis 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 aWaitForFirstConsumerStorageClass a disk that no VM has attached yet would otherwise never populate at all. It costs something on a node-pinned class such aslocal, 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 (anodeSelector, a resource request only one node satisfies, or the Windows affinity applied by_cluster.scheduling.dedicatedNodesForWindowsVMs) can stay unschedulable against a node-affinity conflict, andstorageClassis immutable so the only exit is deleting and recreating the disk. TurnbindImmediatelyoff 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 defaultreplicatedbindsImmediateregardless, so neither setting changes anything there.
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 |