feat(backups): support restore-to-copy rename for standalone VMDisk via the Velero strategy #4428

Summary

A RestoreJob for a standalone VMDisk (Velero strategy, cozy-default-velero-vmdisk) that sets spec.targetApplicationRef.name to a new name and options.targetNamespace to another namespace cannot restore the disk under the new name. Since #4426 such a RestoreJob fails up front with an explicit message (before that it reported Succeeded with the disk still named after the source, see #3537). This issue tracks actually supporting the rename.

Why it does not work today

postRestoreRename (internal/backupcontroller/velerostrategy_controller.go) only knows the VMInstance HelmRelease layout: it looks up vm-instance-<source> in the target namespace, which does not exist for a VMDisk, and returns. Generalizing the HelmRelease name (helmReleaseNameForApp already yields vm-disk-<name>) is not enough:

• The VMDisk Velero strategy backs up the HelmRelease, the PVC and ConfigMaps, not the DataVolume. On a copy restore, the PVC lands in the target namespace as vm-disk-<source> with cdi.kubevirt.io/allowClaimAdoption: "true" (added by the resource modifier), and the restored HelmRelease vm-disk-<source> renders a DataVolume of the same name that adopts it.
• A renamed HelmRelease vm-disk-<target> renders a DataVolume vm-disk-<target>, which adopts nothing and populates a fresh, empty PVC from the chart's source. The restored data stays under vm-disk-<source> next to it.
• A VMInstance is different: its disks are separate vm-disk-* releases that keep their names, so renaming only the vm-instance-* HelmRelease re-attaches the restored volumes.

Proposed approach

After the Velero Restore reaches Completed, for VMDisk:

1. Delete the DataVolume vm-disk-<source> in the target namespace with Orphan propagation (Flux will usually have rendered it already from the restored HelmRelease; the restore must not race it).
2. Rebind the PVC vm-disk-<source> to vm-disk-<target> (the renamePVC PV-rebind mechanism), carrying over labels and annotations. renamePVC today builds a bare spec and drops cdi.kubevirt.io/allowClaimAdoption, without which the new DataVolume will not adopt the PVC.
3. Rename the HelmRelease vm-disk-<source> to vm-disk-<target> (postRestoreRename with helmReleaseNameForApp, and app.kubernetes.io/instance set to the new release name).
4. Drop the VMDisk case from the guard added in fix(backups): fail Velero RestoreJob rename for non-VMInstance kinds #4426.

Flux reconciling the restored vm-disk-<source> HelmRelease while steps 1–3 run is the main hazard; suspending that HelmRelease first (or restoring it suspended) is probably required.

Testing

Unit coverage for the rebind/rename steps plus an e2e restore-to-copy-with-rename round-trip. #3427 modernizes the VMDisk backup/restore e2e (examples/backups/vmdisk/, hack/e2e-chainsaw/vminstance/), but it only covers in-place VMDisk restore and a VMInstance copy without rename, so a new scenario is needed.

Related

• bug(backups): RestoreJob targetApplicationRef rename is silently ignored for Velero-backed non-VM apps #3537 — the original silent-Succeeded bug
• fix(backups): fail Velero RestoreJob rename for non-VMInstance kinds #4426 — kind-aware guard that rejects the rename explicitly
• fix(backups): prepare standalone VMDisk restore targets and add VM backup/restore e2e round-trips #3427 — VMDisk in-place restore driver fix and e2e