What happened : When creating a <code class="notran

I found a solution to my problem after reading: <a href="https://github.com/kubevirt/c

DataVolume import - volume node affinity conflict about containerized-data-importer HOT 2 CLOSED

ianb-mp commented on August 11, 2024

DataVolume import - volume node affinity conflict

from containerized-data-importer.

Comments (2)

ianb-mp commented on August 11, 2024

I also tried creating 2 new storage classes - one for each node, then modifying the DV to use one of these:

storage classes

$ kubectl get storageclass
NAME                      PROVISIONER          RECLAIMPOLICY   VOLUMEBINDINGMODE      ALLOWVOLUMEEXPANSION   AGE
openebs-hostpath          openebs.io/local     Delete          WaitForFirstConsumer   false                  2d
openebs-zfspv (default)   zfs.csi.openebs.io   Delete          Immediate              false                  2d
openebs-zfspv-srv-6       zfs.csi.openebs.io   Delete          Immediate              false                  6m35s
openebs-zfspv-vr-3        zfs.csi.openebs.io   Delete          Immediate              false                  6m33s

Modified DV:

apiVersion: cdi.kubevirt.io/v1beta1
kind: DataVolume
metadata:
  name: rocky9
  namespace: vm-images
spec:
  source:
    http:
      url: http://10.2.3.2/rocky/rocky9.qcow2
  pvc:
    storageClassName: openebs-zfspv-srv-6
    accessModes:
      - ReadWriteOnce
    resources:
      requests:
        storage: 11Gi

where storage class openebs-zfspv-srv-6 manifest is:

apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  name: openebs-zfspv-srv-6
parameters:
  recordsize: "128k"
  compression: "off"
  dedup: "off"
  fstype: "zfs"
  poolname: "zfspv-pool"
provisioner: zfs.csi.openebs.io
allowedTopologies:
- matchLabelExpressions:
  - key: openebs.io/nodeid
    values:
      - bne-lab-srv-6

However that has the same problem as before - PVs on different nodes, and importer pod failing to start:

$ kubectl get pv
NAME                                       CAPACITY   ACCESS MODES   RECLAIM POLICY   STATUS   CLAIM                                                          STORAGECLASS          VOLUMEATTRIBUTESCLASS   REASON   AGE
pvc-70109904-972f-48ff-9ce2-d53b5110ada0   11Gi       RWO            Delete           Bound    vm-images/prime-7a145994-7d01-489c-af16-d315557a0042-scratch   openebs-zfspv         <unset>                          3m50s
pvc-d2b7ffb8-239e-46fb-8d6b-41f4bb0f8504   11Gi       RWO            Delete           Bound    vm-images/prime-7a145994-7d01-489c-af16-d315557a0042           openebs-zfspv-srv-6   <unset>                          3m57s

In the case where a storage class was explicitly set for the backing PVC, I would expect the scratch PVC to also use that rather than the default storage class.

from containerized-data-importer.

ianb-mp commented on August 11, 2024

I found a solution to my problem after reading: https://github.com/kubevirt/containerized-data-importer/blob/main/doc/waitforfirstconsumer-storage-handling.md

change my storage class binding mode from Immediate to WaitForFirstConsumer
add annotation to my DV: cdi.kubevirt.io/storage.bind.immediate.requested: "true"

This also resolved the issue of scratch PVC not using same storage class as backing PVC.

from containerized-data-importer.

Recommend Projects