Hi,

1) Did the NVMe plugin support NVMe over TCP, NVMe over RDMA , or just  NVMe over FC ?
2) Should we test it with real NVMe over FC HW or simulation test it ？
3) what function cover in this plugin ? 
4) Do we have any tests for it?

(In reply to guazhang from comment #1)
> Hi,
> 
> 1) Did the NVMe plugin support NVMe over TCP, NVMe over RDMA , or just  NVMe
> over FC ?

All of these are supported (and the loop target is also supported).

> 2) Should we test it with real NVMe over FC HW or simulation test it ？

I think for the libblockdev support, using the loop target for testing should be enough. I expect that RTT will test the Anaconda/Blivet part on real hardware too (depending on what hardware is available to them).

> 3) what function cover in this plugin ? 

I expect we'll use only the functionality for getting information about the NVMe devices and controllers and the discover and connect/disconnect. The plugin also supports formatting the namespaces and SMART testing for NVMe drives but we do not plan to use these in RHEL. API documentation for the plugin is available here http://storaged.org/libblockdev/3.0/libblockdev-NVMe.html

> 4) Do we have any tests for it?

We have tests for the plugin upstream and these will be backported as well and run in gating together with the rest of the upstream test suite. https://github.com/storaged-project/libblockdev/blob/master/tests/nvme_test.py

@tbzatek is the author of the plugin so he might be able to provide more detailed answers.

(In reply to guazhang from comment #1)
> 1) Did the NVMe plugin support NVMe over TCP, NVMe over RDMA , or just  NVMe
> over FC ?

The libblockdev nvme plugin is generally transport agnostic and is supposed to be like that. Future transports and new options should be just passed further down the stack. It's up to the kernel to process the particular transport arguments. There's some transport-specific code in libnvme but it's generally also open to any use cases.

There might be more transport-specific logic in upper layers, i.e. blivet.

> 2) Should we test it with real NVMe over FC HW or simulation test it ？

The loop transport has very limited functionality and doesn't reflect real use scenarios. We need to test libblockdev against PCIe NVMe devices as well with real fabrics transports. We do that mostly manually upstream and there are no tests for that. The libblockdev test suite is built around the loop target as that's the only available NVMe emulation for use in the CI.

Generally testing NVMe in upper layers, i.e. blivet and udisks, should cover most libblockdev scenarios so I don't think it's necessary to test libblockdev explicitly. Libnvme is also being covered by nvme-cli tests.

Thanks both for the explain. 

I will call the libblockdev or udisks2 to test NVMe plugin if I get real NVMe over FC server.
looks current udisks2 （udisks2-2.9.4-3.el9.x86_64）don't support NVMe, maybe will update later.

Do you think we need test all transport of nvme over TCP/FC/RDMA, or just force one ?

(In reply to guazhang from comment #4)
> looks current udisks2 （udisks2-2.9.4-3.el9.x86_64）don't support NVMe, maybe
> will update later.

That's correct, we don't plan NVMe support in UDisks in RHEL 9. While almost finished upstream, it will only be pushed to Fedora 37/38 and RHEL 10.

> Do you think we need test all transport of nvme over TCP/FC/RDMA, or just
> force one ?

I think this might be worth cooperation with RTT or Kernel (Storage) QE. Gating will be covered by the loop target and the local upstream tests. NVMeoFC needs a specific hardware and NVMe/TCP needs more complex setup. I'll follow up on this in the coming weeks, this is something we plan to discuss cross-team.

https://gitlab.com/redhat/centos-stream/rpms/libblockdev/-/merge_requests/13

Hi,
move to verified since the regression have pass.

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 (libblockdev bug fix and enhancement update), 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/RHBA-2023:2172