MountVolume Error vSphere OKD 4.5

[creativie]

Kubelet can't mount new volume to pod

MountVolume.MountDevice failed for volume "pvc-46ef990e-a9f8-4286-a439-931d9086a456" : rpc error: code = Unknown desc = Exception calling application: Unexpected error while running command. Command: lsblk -nlfoFSTYPE /var/lib/ember-csi/vols/9fa27601-931c-4573-af8d-d4dea0cb95b6 Exit code: 1 Stdout: u'' Stderr: u'lsblk: /var/lib/ember-csi/vols/9fa27601-931c-4573-af8d-d4dea0cb95b6: not a block device\n'

Disk image file exist

~ # file /var/lib/ember-csi/vols/9fa27601-931c-4573-af8d-d4dea0cb95b6
/var/lib/ember-csi/vols/9fa27601-931c-4573-af8d-d4dea0cb95b6: VMware4 disk image

[Akrog]

I didn't know that the VMWare driver actually downloaded the VMDK file instead of doing a real attach.

This means that Ember-CSI doesn't currently support it, because we don't actually have a real block device we can use, so Ember-CSI would need to mount that file to get a real block device.

There are several tools that Ember-CSI could use to do the mounting in order to support these volumes:

• qemu-nbd
• affuse from afftools
• vmware-mount (I believe this is available in the Virtual Disk Development Kit)

This is similar to the QCOW2 files used by the NFS Cinder drivers (currently unsupported but in the TODO list) where we need to mount the files and raw block multi-attach would not work, but in this case it would be even worse, because features like online snapshots would not work and would need to be disabled (since we are working with a local copy of the file), and even worse moving a container from one host to another without a clean disconnect of the source volume would mean that the new node would get the old disk instead of the new one.

Given these limitations we'll be disabling these drivers from the Operator like we are doing with the NFS drivers until we add support for them.

We are really sorry for the time you spent testing it, and we really appreciate the reported bugs.