Description of problem: When VM uses an existing populated PVC, DV's export manifest can't be applied. Version-Release number of selected component (if applicable): 4.14 How reproducible: Always Steps to Reproduce: 1. Create a DV/PVC on CSI storage (it will use populators) $ virtctl image-upload dv cirros-dv --image-path=./cirros-0.4.0-x86_64-disk.qcow2 --size=1Gi --storage-class=ocs-storagecluster-ceph-rbd --insecure 2. Create a VM that will use this PVC apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-from-uploaded-dv spec: running: true template: spec: domain: devices: disks: - disk: bus: virtio name: pvc-edd0ce9a-2c84-46b3-bc42-7450c2f8602b rng: {} resources: requests: memory: 100Mi volumes: - name: pvc-edd0ce9a-2c84-46b3-bc42-7450c2f8602b persistentVolumeClaim: claimName: cirros-dv 3. Create a VMExport and save manifests $ virtctl vmexport download export --manifest --vm=vm-from-uploaded-dv --include-secret --output=manifest.yaml 4. Add/replace the 'namespace: target' in the manifest.yaml 5. Try to create a target VM: $ oc create -f manifest.yaml configmap/export-ca-cm-export created virtualmachine.kubevirt.io/vm-from-uploaded-dv created secret/header-secret-export created Error from server: error when creating "manifest.yaml": admission webhook "datavolume-validate.cdi.kubevirt.io" denied the request: External population is incompatible with Source and SourceRef DataSourceRef and DataSource must match 6. DataVolume from manifest.yaml: --- apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: creationTimestamp: null name: cirros-dv namespace: target spec: pvc: accessModes: - ReadWriteMany dataSource: apiGroup: cdi.kubevirt.io kind: VolumeUploadSource name: volume-upload-source-aa30e962-d15e-4a5f-a88d-95e1989c6fbd dataSourceRef: apiGroup: cdi.kubevirt.io kind: VolumeUploadSource name: volume-upload-source-aa30e962-d15e-4a5f-a88d-95e1989c6fbd resources: requests: storage: "1073741824" volumeMode: Block source: http: certConfigMap: export-ca-cm-export secretExtraHeaders: - header-secret-export url: https://virt-exportproxy-openshift-cnv.<mypath>/api/export.kubevirt.io/v1alpha1/namespaces/default/virtualmachineexports/export/volumes/cirros-dv/disk.img.gz status: {} --- Actual results: Error from server: error when creating "manifest.yaml": admission webhook "datavolume-validate.cdi.kubevirt.io" denied the request: External population is incompatible with Source and SourceRef DataSourceRef and DataSource must match Expected results: VM and DV/PVC were created successfully in the target namespace/cluster Additional info: When VM uses dataVolumeTemplates - we don't hit this issue and it works fine.
Verified on CNV v4.14.0.rhel9-1576 Just a note: If you're using this feature, you might want to add a storage class to the DataVolume yaml, because it has a 'pvc' api, and 'accessModes' and 'volumeMode' are specified. So if you will not specify a 'storageClassName', and the default storage class will not support those 'accessModes' and 'volumeMode', import will fail. apiVersion: cdi.kubevirt.io/v1beta1 kind: DataVolume metadata: creationTimestamp: null name: cirros-dv-target namespace: target spec: pvc: accessModes: - ReadWriteMany resources: requests: storage: "1073741824" volumeMode: Block storageClassName: ocs-storagecluster-ceph-rbd <--------- might want to add Or you can use a 'storage' api, then you can completely remove the 'accessModes' and 'volumeMode', they'll be taken from the storageProfile: spec: storage: resources: requests: storage: "1073741824" And this would be a better yaml for a VM, that is using an existing DV (dataVolume instead of persistentVolumeClaim, like in the bug description) $ cat vm-from-uploaded-dv-dv.yaml apiVersion: kubevirt.io/v1 kind: VirtualMachine metadata: name: vm-from-uploaded-dv spec: running: true template: spec: domain: devices: disks: - disk: bus: virtio name: dv-disk rng: {} resources: requests: memory: 100Mi volumes: - dataVolume: name: cirros-dv name: dv-disk
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