Description of problem: When cloning a VM disk we want it to complete quickly but it can revert back to the slower host-assisted method for many different reasons. The logic is complex enough that a KCS article was written to help diagnose the reason: https://access.redhat.com/articles/7021609 Since the diagnostic steps are concrete we should be able to automatically provide a reason that host-assisted cloning is used so that the issue can be resolved. Version-Release number of selected component (if applicable): 4.14.0 and earlier How reproducible: Variable, depending on storage configuration. Steps to Reproduce: One way to reproduce this is by cloning to a PVC with a different volume mode 1. Determine the volume mode of the source PVC 2. Ensure "smart" cloning works when cloning a source PVC to a PVC with the same volume mode. 3. Create a DV to clone the source PVC and specify a different volume mode Actual results: The clone completes successfully but uses host-assisted cloning. There is no clear information available (in the PVC nor in events) to explain why host-assisted cloning was used. Expected results: The PVC is annotated with a clone fallback reason and an event is generated. Additional info:
Verified with the following code: --------------------------------------------------------------- oc get csv -n openshift-cnv NAME DISPLAY VERSION REPLACES PHASE kubevirt-hyperconverged-operator.v4.14.0 OpenShift Virtualization 4.14.0 kubevirt-hyperconverged-operator.v4.13.2 Succeeded openshift-pipelines-operator-rh.v1.11.0 Red Hat OpenShift Pipelines 1.11.0 Succeeded Deployed: CNV-v4.14.0.rhel9-1508 oc version Client Version: 4.14.0-ec.3 Kustomize Version: v5.0.1 Server Version: 4.14.0-ec.3 Kubernetes Version: v1.27.3+e8b13aa Verified with the following scenario: ---------------------------------------------------------------- 1. Create a source dv with volume mode Block on sc ocs-storagecluster-ceph-rbd 2. Create a target dv clone of the source dv >>>>> The dv clone annotation states the reason for fallback: oc get events: 38m Warning IncompatibleVolumeModes persistentvolumeclaim/target-dv-cephfs The volume modes of source and target are incompatible oc get pvc target-dv-cephfs -oyaml apiVersion: v1 kind: PersistentVolumeClaim metadata: annotations: cdi.kubevirt.io/cloneFallbackReason: The volume modes of source and target are incompatible cdi.kubevirt.io/clonePhase: Succeeded cdi.kubevirt.io/cloneType: copy cdi.kubevirt.io/storage.condition.running: "false" cdi.kubevirt.io/storage.condition.running.message: Clone Complete cdi.kubevirt.io/storage.condition.running.reason: Completed cdi.kubevirt.io/storage.contentType: kubevirt cdi.kubevirt.io/storage.pod.restarts: "0" cdi.kubevirt.io/storage.populator.progress: 100.0% cdi.kubevirt.io/storage.preallocation.requested: "false" cdi.kubevirt.io/storage.usePopulator: "true" pv.kubernetes.io/bind-completed: "yes" pv.kubernetes.io/bound-by-controller: "yes" volume.beta.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com volume.kubernetes.io/storage-provisioner: openshift-storage.cephfs.csi.ceph.com creationTimestamp: "2023-08-13T13:54:45Z" finalizers: - kubernetes.io/pvc-protection Moving this bug to VERIFIED!
*** Bug 2227100 has been marked as a duplicate of this bug. ***
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory (Important: OpenShift Virtualization 4.14.0 Images security and bug fix update), and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2023:6817