bug(vm-disk): editing storageClass/source on an existing VMDisk is silently ignored #2985

Summary

Editing a VMDisk's storageClass (or source) after its DataVolume already exists has no effect and surfaces no warning. The typed CR accepts the edit and the HelmRelease reports success, but the DataVolume keeps its original spec — the source of truth and the cluster silently diverge.

Mechanism

packages/apps/vm-disk/templates/dv.yaml looks up an existing DataVolume and, when one is found, reuses its spec verbatim:

{{- $existingDV := lookup "cdi.kubevirt.io/v1beta1" "DataVolume" .Release.Namespace .Release.Name }}
spec:
  {{- if $existingDV }}
    {{- toYaml $existingDV.spec | nindent 2 }}
  {{- else }}
    ... (builds spec from .Values: source, storageClass, storage)
  {{- end }}

So .Values.storageClass / .Values.source are honored only on initial creation. Every later edit renders the old spec and is a no-op.

Why it matters

DataVolume.spec is immutable in CDI, so reusing it avoids an invalid update — but doing so silently means an operator who edits the VMDisk CR gets "success" while nothing changes. Storage size growth is already handled explicitly via pvc-resize-hook.yaml; storageClass/source changes have no equivalent and no diagnostic.

Reproduce

1. Create a VMDisk on StorageClass A, let it import/bind.
2. Edit .spec.storageClass to B.
3. The DataVolume/PVC stay on A; no error, HelmRelease Ready. Only deleting the DataVolume and forcing a re-render moves it to B.

Suggested fix

When the rendered spec would differ from the existing DataVolume's immutable fields (storageClass/source), fail() with a clear message ("VMDisk storageClass/source is immutable after creation — delete and recreate the disk to change it"), mirroring the explicit handling already done for size. Documenting the immutability would be the minimum.

Related: #2908 (same file, different mechanism — golden-image cross-StorageClass clone hang).