You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
What I expect: /dev/nvme0n1 being created and usable on the client.
Note: reproducing these exact commands without using --enable-ha and --ana-reporting options when creating the subsystem results in /dev/nvme0n1 being created on the client as expected.
The text was updated successfully, but these errors were encountered:
FredNass
changed the title
[1.0.0] No /dev/nvme0n1 and null nvme list on EL9.3 client with --enable-ha --ana-reporting
[1.0.0] No /dev/nvme0n1 and null nvme list on EL9.3 client with --enable-ha and --ana-reporting
Feb 23, 2024
@FredNass you are correct. The auto HA mode is still not functional. It waits for the nvmeof monitor code to be merged to ceph. You can see here.
The temporary way to use auto ha now is to use a special ceph builds, with a sha that we update when needed here (CEPH_SHA=).
Thank you @caroav. Are there any publicly available containers associated with this special build (ceph-19.0.0-1365.g4b2ae236) that one could use for testing purposes? By changing container_image setting of a test cluster for example?
ceph config set global container_image quay.io/ceph/ceph@sha256:<CEPH_SHA>
Hello,
In order to evaluate how ceph-nvmeof behaves in a HA setup, I've set up 2 GWs as per below:
ceph-nvmeof.conf of GW #1 test-lis04h02:
ceph-nvmeof.conf of GW #2 test-mom02h02:
Deleting rados config object:
Started two [1.0.0] containers on nodes test-lis04h02 and test-mom02h02 with below options:
And configured the GWs:
suybsystem and namespace configuration check:
What I observe: /dev/nvme0n1 is not created on test-mom02h01 EL 9.3 client.
/dev/nvme0n1 is not created on the client.
What I expect: /dev/nvme0n1 being created and usable on the client.
Note: reproducing these exact commands without using --enable-ha and --ana-reporting options when creating the subsystem results in /dev/nvme0n1 being created on the client as expected.
The text was updated successfully, but these errors were encountered: