Description of problem: When uploading an image using "virtctl image-upload dv <dvname> ...", the upload times out if the dvname includes a ".". For example, this command succeeds: [kni@neu-17-25 hostpath]$ virtctl image-upload dv larsdv4 --image-path cirros-0.5.1-x86_64-disk.img --storage-class hostpath-provisioner --insecure --pvc-size 1Gi DataVolume default/larsdv4 created Waiting for PVC larsdv4 upload pod to be ready... Pod now ready Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.cnv.massopen.cloud 15.58 MiB / 15.58 MiB [==========================================================================================================================================================] 100.00% 0s Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress Processing completed successfully Uploading cirros-0.5.1-x86_64-disk.img completed successfully But this command -- identical except for the dv name -- fails with a timeout: [kni@neu-17-25 hostpath]$ virtctl image-upload dv larsdv4.0 --image-path cirros-0.5.1-x86_64-disk.img --storage-class hostpath-provisioner --insecure --pvc-size 1Gi DataVolume default/larsdv4.0 created Waiting for PVC larsdv4.0 upload pod to be ready... timed out waiting for the condition Version-Release number of selected component (if applicable): kubevirt-virtctl-0.26.1-15.el8.x86_64
We use --pvc-size and --pvc-name together. Now they're DEPRECATED flags. Try dv and --size like examples mentioned: [cloud-user@ocp-psi-executor qwang]$ virtctl image-upload dv larsdv4.0 --image-path cirros-0.4.0-x86_64-disk.qcow2 --storage-class hostpath-provisioner --insecure --size 1Gi DataVolume test-hostpath/larsdv4.0 created Waiting for PVC larsdv4.0 upload pod to be ready... Pod now ready Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.zpeng-cnv24.cnv-qe.rhcloud.com 12.13 MiB / 12.13 MiB [=====================================================================================================================] 100.00% 0s Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress Processing completed successfully Uploading cirros-0.4.0-x86_64-disk.qcow2 completed successfully [cloud-user@ocp-psi-executor qwang]$ oc get pvc NAME STATUS VOLUME CAPACITY ACCESS MODES STORAGECLASS AGE larsdv4.0 Bound pvc-7c7d9646-4b7c-4023-8ed6-19ffff107844 48Gi RWO hostpath-provisioner 2m51s [cloud-user@ocp-psi-executor qwang]$ oc get dv NAME PHASE PROGRESS RESTARTS AGE larsdv4.0 Succeeded N/A 0 4m59s So the DV name includes a "." is acceptable.
Correct handling of a '.' (dot character) in the dv name was fixes in PR #1200 https://github.com/kubevirt/containerized-data-importer/pull/1200, it is included in release v1.18.0: https://github.com/kubevirt/containerized-data-importer/releases/tag/v1.18.0 There are even new tests for this problem: "[test_id:4275] Upload datavolume with long name including special chars '.' - creates correct scratch space, pod and service names"
Verified, CNV 2.4, no issues with creating data volumes with "." in the data volume name. $ virtctl image-upload dv test.5 --image-path cirros-0.4.0-x86_64-disk.qcow2 --storage-class hostpath-provisioner --insecure --pvc-size 1Gi DataVolume default/test.5 created Waiting for PVC test.5 upload pod to be ready... Pod now ready Uploading data to https://cdi-uploadproxy-openshift-cnv.apps.cnv-qe.rhcloud.com 12.13 MiB / 12.13 MiB [===============================================================================================================================================] 100.00% 0s Uploading data completed successfully, waiting for processing to complete, you can hit ctrl-c without interrupting the progress Processing completed successfully Uploading cirros-0.4.0-x86_64-disk.qcow2 completed successfully
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, 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-2020:3194