kubernetes-nodes: golden-image StorageClass guard states a CDI fallback that does not happen under csi-clone #4849

The kubernetes-nodes guard for osImage.builtin refuses a pool whose StorageClass differs from the golden image's, and the reason it gives is not what CDI does under the platform default. The comment and the error message both say that CDI cannot CSI-clone across StorageClasses and would fall back to a host-assisted copy over the pod network. With cloneStrategyOverride: csi-clone, which packages/system/kubevirt-cdi/values.yaml ships, there is no such fallback.

Mechanism

CDI picks the clone path without looking at class names. In v1.66.1, the version the platform pins, computeStrategyForSourcePVC in pkg/controller/clone/planner.go takes the global override first. validateAdvancedClonePVC then falls back to a host-assisted copy in three cases only: a different driver, a different volume mode, or a larger target in a class without expansion. With LINSTOR on both sides none of these apply, so CDI takes the CSI clone path and nothing is copied over the pod network.

What happens next depends on the target class. linstor-csi v1.11.2, which the platform ships, creates the clone next to the source data. The clone can bind on any node only when the target class allows remote volume access from anywhere (allowRemoteVolumeAccess).

So the guard does keep a pool out of a node-local class, where the clone may never bind. That is the case behind #2908. But it also refuses a pool in a second remote-accessible LINSTOR class, where CDI does a storage-level CSI clone, the same as for a matching class. The stated reason holds only under the copy strategy.

Location

packages/apps/kubernetes-nodes/templates/nodegroup.yaml: the comment that starts "CDI takes the storage-layer CSI-clone path only when source and target share a StorageClass" and the fail message after it. Both came in with bc8c54d.

What could be done

1. Fix the comment and the error message so they describe what CDI actually does.
2. Decide whether to narrow the guard the way fix(vm-disk)!: refuse a golden-image clone CDI would leave unbound #4796 narrows the vm-disk one, or keep it strict on purpose. Narrowed, it would refuse a CSI clone into a LINSTOR class without remote access from anywhere, plus the copy strategy, where the host-assisted copy is exactly what the pool tries to avoid.

I haven't reproduced this on a cluster. It comes from reading the CDI and linstor-csi sources at the pinned versions.