Bug 2231479 - Cannot clone DataVolume from "local" to rook-ceph-block
Summary: Cannot clone DataVolume from "local" to rook-ceph-block
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Container Native Virtualization (CNV)
Classification: Red Hat
Component: Storage
Version: 4.14.0
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ---
: 4.14.1
Assignee: Michael Henriksen
QA Contact: Harel Meir
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-08-11 17:04 UTC by Michael Henriksen
Modified: 2023-12-07 15:00 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-12-07 15:00:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github kubevirt containerized-data-importer pull 2840 0 None open Fix broken local -> rook-ceph-block clone 2023-08-11 17:08:57 UTC
Github kubevirt containerized-data-importer pull 2842 0 None Merged [release-v1.57] Fix broken local -> rook-ceph-block clone 2023-11-15 19:14:55 UTC
Red Hat Issue Tracker CNV-31991 0 None None None 2023-08-11 17:06:10 UTC
Red Hat Product Errata RHSA-2023:7704 0 None None None 2023-12-07 15:00:48 UTC

Description Michael Henriksen 2023-08-11 17:04:38 UTC
Description of problem:

With 4.14, the StorageProfile for rook-ceph-block is configured to prefer csi-clone cloning strategy.  That works fine when the source/target PVC are both on rook-ceph-block.  But if the source is on another storageclass, like "local", then the clone operation hangs forever.  The clone populator will attempt to csi clone from the "local" storage class which obviously does not work.


Version-Release number of selected component (if applicable):


How reproducible: 100%


Steps to Reproduce:
1.  Create source DataVolume in "local" storageclass
2.  Create target DataVolume in rook-ceph-block storageclass with `spec.source.pvc` referring to PVC created in previous step
3.  Observe DataVolume stuck in CSIClone phase

Actual results:  DataVolume stuck in CSIClone phase


Expected results:  DataVolume succeeds


Additional info:

Comment 1 Adam Litke 2023-09-27 18:18:49 UTC
Build is downstream but not included in errata yet.  Pushing to 4.14.1.

Comment 2 Harel Meir 2023-11-20 16:41:12 UTC
Verified in 4.14.1

Steps:

1. Creating source DV as hpp:

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: dv-source
  namespace: default
  annotations:
    cdi.kubevirt.io/storage.bind.immediate.requested: 'true'
spec:
  source:
      http:
         url: "http://cnv-qe-server.cnv-qe.rhood.us/files/cnv-tests/cirros-images/cirros-0.4.0-x86_64-disk.qcow2"
  storage:
    resources:
      requests:
        storage: 1Gi
    storageClassName: hostpath-csi-basic


2. Create a target-dv with ocs-virt SC(csi-clone) that clones the source-dv

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: dv-target
  namespace: default
  annotations:
    cdi.kubevirt.io/storage.bind.immediate.requested: 'true'
spec:
  source:
    pvc:
      name: dv-source
      namespace: default
  storage:
    resources:
      requests:
        storage: 1Gi
    storageClassName: ocs-storagecluster-ceph-rbd-virtualization


3. The Dv succeeded and PVC bound:

$ oc get dv,pvc
NAME                                       PHASE       PROGRESS   RESTARTS   AGE
datavolume.cdi.kubevirt.io/dv-source-hpp   Succeeded   100.0%     1          10m
datavolume.cdi.kubevirt.io/dv-target       Succeeded   100.0%                3m7s

NAME                                  STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS                                 AGE
persistentvolumeclaim/dv-source-hpp   Bound    pvc-c7299a44-cd28-450f-ac0b-663ea36b621f   149Gi      RWO            hostpath-csi-basic                           10m
persistentvolumeclaim/dv-target       Bound    pvc-021e67c0-287c-42ea-8e8f-b3ba5148a1f0   1Gi        RWX            ocs-storagecluster-ceph-rbd-virtualization   3m

Comment 9 errata-xmlrpc 2023-12-07 15:00:46 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.1 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:7704


Note You need to log in before you can comment on or make changes to this bug.