Bug 2227013

Summary:	It is difficult to understand why VM disk cloning reverts to the host-assisted method
Product:	Container Native Virtualization (CNV)	Reporter:	Adam Litke <alitke>
Component:	Storage	Assignee:	Arnon Gilboa <agilboa>
Status:	CLOSED ERRATA	QA Contact:	Kevin Alon Goldblatt <kgoldbla>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	4.14.0	CC:	awels, gouyang, joherr
Target Milestone:	---
Target Release:	4.14.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:	v4.14.0.rhel9-1387	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2023-11-08 14:06:16 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Adam Litke 2023-07-27 12:54:03 UTC

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:

Comment 1 Kevin Alon Goldblatt 2023-08-13 14:43:39 UTC

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!

Comment 3 Arnon Gilboa 2023-09-05 18:34:40 UTC

*** Bug 2227100 has been marked as a duplicate of this bug. ***

Comment 4 errata-xmlrpc 2023-11-08 14:06:16 UTC

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