Configured reservation key doesn't match: 0x0 #92
Comments
|
Check your |
looks correct on both nodes (the other one is 0x1), unless I'm missing something? |
|
I feel like I have a lead on this, but I'm not sure. I found a thread from 2010 that suggests that all 6 active round robin ports that hold a particular active key (e.g. 0x1) should be able to access the SCSI device at the same time, however, when the scripts run, only 1 path out of 6 becomes a reservation holder. Does anyone have any hints as to what I should change to fix this behaviour? |
|
To my understanding, all paths with the same key as the reservation holder (0x1) should be able to access the LUN. Otherwise I'd assume that multipathd would show them as failed. Can you confirm? |
Sorry, wasn't sure how to confirm that. Does this help? |
|
Sorry, I was mistaken. According to the SCSI spec, with reservation type 5 (Write exclusive / registrants only), only one I/T nexus is the reservation holder. Write access should be allowed for every registered I_T nexus (i.e. both nodes; you could test this by writing to the SCSI devices but that would of course be dangerous). So what you report above is correct, AFAICT. Can you try running the above mpathpersist command with |
|
Thanks for the help! Here's the output, though I apologize for how long it is... very long code block |
|
Martin was wondering if you could run this command |
|
the output of |
|
Don't bother with the command outputs. I can reproduce this myself. It looks to be a legit mpathpersist bug. I'll work up a fix next week. |
|
I know you said not to bother, but on the off chance it helps: preempt-abort with -v4multipath -T |
|
Sent a fix for this to dm-devel. |
|
We built v0.9.4 and added this patch to the list of patches from debian's maintainers and are currently running it on 2x debian 12 hosts. The error looks to be resolved and so far no negative effects have reared their head (though its been only 2 days). Looks good overall, thank you! I will leave this issue open for you to tie in to the next pull from the queue. |
|
Thanks a lot, @bmarzins! It's strange that this hasn't caused issues earlier, the affected code is ancient. |
|
@bmarzins, I don't quite understand your explanation yet why we haven't seen this error before. "This appeared to work for many commands because of an error in checking if the correct reservation key was used." The code that compared Is it just that? Many of the "simple" PROUT commands just need either RK or SARK, and other commands would always have failed, but nobody noticed? |
|
Yep. The following commands wouldn't fail before, because the command doesn't set both the RK and SARK. registering a key: reserving a device: clearing a reservation: clearing a registration: As long as nothing goes wrong, those may well be the only commands that ever get run. But doing something like preempting and aborting an existing reservation fails, since it requires both a RK (which should match mpp->reservation_key) and a SARK: Also, this only fails for configurations where the key is set in the multipaths section. It works fine if reservation_key is set to "file" in the defaults section, which is much easier to configure, and what, I assume, most people are using. |
|
Right ... "file" would be set in the defaults section, not the multipaths section. That was the part I'd been missing. Thanks. |
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hello,
I can't seem to narrow down this error. On running this command:
/usr/sbin/mpathpersist -o --preempt-abort --prout-type=5 --param-rk=1 --param-sark=2 -d /dev/mapper/san0I receive this error:
san0: configured reservation key doesn't match: 0x0However, 0x0 doesn't match any configured keys:
There are 2 hosts running a Pacemaker stack using
fence_mpathto generate the commands, with the keys 1 and 2 respectively. Other commands seem to work fine, I'm just unable to figure out why there's a failure. I have tried manually releasing the reservation, but it ends up at the same place eventually.I am running Debian 12 with multipath-tools 0.9.4
Any help is appreciated, thanks!
The text was updated successfully, but these errors were encountered: