May need to add the flag her `--access-mode` or use the method of creating the dv first as in: https://docs.openshift.com/container-platform/4.7/virt/virtual_machines/virtual_disks/virt-uploading-local-disk-images-virtctl.html The tool can hang without error if access-mode is not specified. https://bugzilla.redhat.com/show_bug.cgi?id=2211568 https://bugzilla.redhat.com/show_bug.cgi?id=2126104 Reported by: rhn-support-dsedgmen https://access.redhat.com/documentation/en-us/red_hat_openstack_platform/16.2/html/rhosp_director_operator_for_openshift_container_platform/assembly_preparing-for-overcloud-deployment-with-the-director-operator_rhosp-director-operator#annotations:4c60564f-6028-40fc-9263-05555dc8d827
So this specifically occurs only if a default access mode hasn't been set on the storage. We could add a note to the docs that customers should pay attention to the access mode either in their storage, or in the image upload command, but it's probably not reasonable for us to explicitly include a specific mode in our command.
I am not sure what you mean. In the use case in the docs the command is meant to create a PVC, which as far as I understand pvc spec requires the accessmode set. Where is the accessmode retrieve derived from when you use `virtctl image-upload dv openstack-base-img -n openstack --size=50Gi --image-path=<local path to image> --storage-class <storage class> --insecure` I my use case the provisioner I am using, it is meant to default to (ReadWriteOnce) but that could be an issue with the provisoner https://github.com/kubernetes-sigs/nfs-subdir-external-provisioner/blob/master/charts/nfs-subdir-external-provisioner/README.md but in the case of my iscsi pv which does have a accessmode set, it still hangs waiting for the pvc to be created kind: PersistentVolume apiVersion: v1 metadata: name: iscsi-pv-01 uid: 548684e5-36e1-4686-90db-bfe5b5b7c04b resourceVersion: '41320730' creationTimestamp: '2023-06-01T00:26:44Z' finalizers: - kubernetes.io/pv-protection managedFields: - manager: kube-controller-manager operation: Update apiVersion: v1 time: '2023-06-01T00:26:44Z' fieldsType: FieldsV1 fieldsV1: 'f:status': 'f:phase': {} subresource: status - manager: kubectl-create operation: Update apiVersion: v1 time: '2023-06-01T00:26:44Z' fieldsType: FieldsV1 fieldsV1: 'f:spec': 'f:accessModes': {} 'f:capacity': .: {} 'f:storage': {} 'f:iscsi': .: {} 'f:fsType': {} 'f:iqn': {} 'f:iscsiInterface': {} 'f:lun': {} 'f:targetPortal': {} 'f:persistentVolumeReclaimPolicy': {} 'f:storageClassName': {} 'f:volumeMode': {} spec: capacity: storage: 100Gi iscsi: targetPortal: '*******' iqn: '*******' lun: 0 iscsiInterface: default fsType: ext4 accessModes: - ReadWriteOnce persistentVolumeReclaimPolicy: Retain storageClassName: iscsi-ssd volumeMode: Filesystem status: phase: Available
I think this should be changed in https://docs.openshift.com/container-platform/4.12/virt/virtual_machines/virtual_disks/virt-uploading-local-disk-images-virtctl.html#virt-uploading-local-disk-image-dv_virt-uploading-local-disk-images-virtctl first and foremost, we can follow what they do there, but that is the canonical source for how to upload the images.