Oh thanks for the clarification!
I'm particularly interested in native multipath (ANA). Are there any plans to have a mechanism for updating/replacing failed paths? E.g. in case when one of the backend paths dies and has to be replaced with a new one - completely new target (let's say cinder driver exposes new path in place of the failed one).
Is there a way to participate in the development?
BR
On 4/1/22 11:03, Gorka Eguileor wrote:
On 01/04, bartosz.rabiega@ovhcloud.com wrote:
Hello,
I'm trying to figure out how the new feature of Yoga works:
"The libvirt driver now allows using Native NVMeoF multipathing for NVMeoF connector, via the configuration attribute in nova-cpu.conf [libvirt]/volume_use_multipath, defaulting to False (disabled)."
https://review.opendev.org/c/openstack/nova/+/823941
It's said that this config value enables native NVMeoF multipathing, but I can't see any support for such configuration in os-brick connector.
https://github.com/openstack/os-brick/blob/master/os_brick/initiator/connect...
Am I missing something?
BR BR
Hi,
You are not missing anything.
Maybe the wording of the nova release note could have been a bit more clear, because what nova has now is the ability to let NVMe-oF use multipathing (once it becomes available in os-brick) for Cinder drivers that support it...
There are 2 kinds of multipathing possible with NVMe-oF:
- Native (ANA)
- Device Mapper (same as with iSCSI an FC)
The team is currently working on adding NVMe-oF native multipathing to os-brick [1], and the DM option will be available later, so it's not available on Yoga.
Once it becomes available in os-brick, Cinder drivers will need to be updated to use the newer connection information format (except the Kioxia driver that already uses it).
Cheers, Gorka.