+++ This bug was initially created as a clone of Bug #1756328 +++
Steps to Reproduce:
1. Have a kubevirt-storage-class-defaults config map which contains "volumeMode: Block" configured for a storage class X
2. Go to the new VM dialog and try to import a VM
3. In the storage section, pick X as a storage class for any or all of the disks
4. Submit the dialog
The conversion pod will never start because it fails to mount the PVCs
The conversion succeeds
The problem is, that if the volume mode is Block, pvc should be mounted using volumeDevices and not volumeMounts
--- Additional comment from Tomáš Golembiovský on 2019-10-10 13:41:59 UTC ---
I have modified entrypoint script to handle the block devices. The change is here:
It requires corresponding change in the pod definition where the disks should be removed from `volumeMounts` section and included in `volumeDevices` section like this:
- name: hdd1
The device path is important and must conform to the name /dev/v2v-diskX where X is a number. This is how the entrypoint will find them during execution.
--- Additional comment from Marek Libra on 2019-10-11 12:54:08 UTC ---
UI patch: https://github.com/kubevirt/web-ui-components/pull/557
Configuration of the temporary disk still needs to be resolved, discussion in progress within the PR.
Patch for temporary disk: https://github.com/kubevirt/web-ui-components/pull/561
Verified that with the fix included from https://github.com/kubevirt/web-ui-components/pull/561, the conversion pod disk has correct accessMode RWO and volumeMode Filesystem and successfully binds using rook-ceph storage class.
The VM import started as expected.
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.