The VirtualMachineClone API currently does not respect the .spec.cloneStrategy defined in the relevant StorageProfile. This leads to inconsistent cloning behavior within the platform.

When cloning a VM, the underlying storage cloning mechanism should be determined by the StorageProfile, just as it is for other provisioning methods. For example, if the StorageProfile specifies a host-based copy (e.g., .spec.cloneStrategy: copy), VirtualMachineClone should honor that setting. Instead, it appears to just ignores the StorageProfile configuration and default to always being based on snapshot.

This enhancement requests that the VirtualMachineClone controller be updated to read and apply the cloneStrategy from the target StorageProfile during the cloning process.

Observed Behavior vs. Expected Behavior

We investigated three different cloning and provisioning scenarios:

• 1. Provision a new VM from a bootable volume:

• • Observed Behavior: Correctly respects the StorageProfile's cloneStrategy.

• • Result: PASS ✅

• 2. Clone a volume using a DataVolume:

• • Observed Behavior: Correctly respects the StorageProfile's cloneStrategy.

• • Result: PASS ✅

• 3. Clone a VM using VirtualMachineClone:

• • Observed Behavior: Does NOT respect the StorageProfile's cloneStrategy.

• • Result: FAIL ❌

The expected behavior is that the cloning process is consistent across all methods. VirtualMachineClone should behave like the other two methods and utilize the configured cloneStrategy at }}{{{}StorageProfile.

User Impact

Having the ability to change cloneStrategy behavior is important. For instance, we are currently using the copy mode to work around an issue with a particular storage hardware.

This inconsistency forces users to manually clone DataVolumes and then create new VMs from them to achieve the desired storage behavior, bypassing the more convenient VirtualMachineClone abstraction. Aligning this behavior will create a more predictable and efficient user experience.

Example of Expected Behavior (DataVolume clone)

The following DataVolume manifest correctly initiates a clone honoring the StorageProfile configuration. VirtualMachineClone should adopt this same logic.
 
apiVersion: cdi.kubevirt.io/v1beta1kind: DataVolumemetadata:name: new-cloned-dvnamespace: defaultspec:source:pvc:name: source-pvc-to-clone # Name of the original source PVCnamespace: demostorage:storageClassName: pflexresources:requests:storage: 32Gi # Size of the original source PVC