The driver claims support for NVMeoF in several places, but in node.go (NodePublishVolume and getVolumeStats), for block volumes (isFSVolume == false / isBlock == true), the code hardcodes the use of d.OsDeviceConnectivityHelper (which is initialized as ScsiGeneric), entirely bypassing the PublishContext connectivity mapping.
That breaks raw block volume support for non-SCSI protocols. That means physical NVMe subsystems (like IBM's supported NVMe/FC systems) will timeout and fail to attach because the node agent incorrectly looks for dm-multipath maps and runs sg_inq instead of using the NVMe driver module to match WWIDs natively.
It took me hours to overcome this in my patch, but eventually I managed to find a way to change this so that I can start a KubeVirt VM that successfully boots from a Block mode PVC backed by NVMe/RoCE storage.
The driver claims support for NVMeoF in several places, but in node.go (NodePublishVolume and getVolumeStats), for block volumes (isFSVolume == false / isBlock == true), the code hardcodes the use of d.OsDeviceConnectivityHelper (which is initialized as ScsiGeneric), entirely bypassing the PublishContext connectivity mapping.
That breaks raw block volume support for non-SCSI protocols. That means physical NVMe subsystems (like IBM's supported NVMe/FC systems) will timeout and fail to attach because the node agent incorrectly looks for dm-multipath maps and runs sg_inq instead of using the NVMe driver module to match WWIDs natively.
It took me hours to overcome this in my patch, but eventually I managed to find a way to change this so that I can start a KubeVirt VM that successfully boots from a Block mode PVC backed by NVMe/RoCE storage.