Mailing List Archive

Antw: Re: Antw: Re: Antw: Re: Antw: Re: SLES11 SP3: warning: crm_find_peer: Node 'h01' and 'h01' share the same cluster nodeid: 739512321
>>> Lars Marowsky-Bree <lmb@suse.com> schrieb am 30.01.2015 um 14:38 in
Nachricht
<20150130133815.GF2171@suse.de>:
> On 2015-01-30T08:23:14, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de>
wrote:
>
>> Two of the three nodes were actually updated from SP1 via SP2 to SP3, and
> the
>> third node was installed with SP3. AFAIR there was no configuration change
>> since SP1.
>
> That must be incorrect, because:
>
>> > Was the corosync.conf option "clear_node_high_bit" changed?
>>
>> # grep -i high /etc/corosync/corosync.conf
>> clear_node_high_bit: new
>>
>> Could this cause our problem?
>
> This is an option that didn't exist prior to SP3.

With "there was no change" meant: No administrator did change the file; if a
package installation changed the file, I'm not aware of it.

>
> And yes, changing this option would cause exactly the issue you've seen.

So it's this phrase from the manual page?:

WARNING: The clusters behavior is undefined if this option
is
enabled on only a subset of the cluster (for example during
a
rolling upgrade).

BTW: The manual page does not says that "nodeid" has to be a positive 32-bit
2-complement; the page just says it's a 32-bit number...

>
> The "old" default behaviour was buggy, but since we couldn't fix it w/o
> this, we introduced "new" and defaulted new clusters to this; existing
> configuration files would remain on their old mode and thus remain
> compatible.
>
>
> Regards,
> Lars
>
> --
> Architect Storage/HA
> SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip

> Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
> "Experience is the name everyone gives to their mistakes." -- Oscar Wilde
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA@lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems



_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems
Re: Antw: Re: Antw: Re: Antw: Re: Antw: Re: SLES11 SP3: warning: crm_find_peer: Node 'h01' and 'h01' share the same cluster nodeid: 739512321 [ In reply to ]
On 2015-01-30T14:57:29, Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> wrote:

> >> # grep -i high /etc/corosync/corosync.conf
> >> clear_node_high_bit: new
> >>
> >> Could this cause our problem?
> > This is an option that didn't exist prior to SP3.
> With "there was no change" meant: No administrator did change the file; if a
> package installation changed the file, I'm not aware of it.

Hrm. It's definitely not an option that is meant to be changed
automatically. Because it would break upgrades if it was. If you have
logs that cover the upgrade process, I'm pretty sure someone would be
willing to investigate.

> > And yes, changing this option would cause exactly the issue you've seen.
>
> So it's this phrase from the manual page?:
>
> WARNING: The clusters behavior is undefined if this option
> is
> enabled on only a subset of the cluster (for example during
> a
> rolling upgrade).

Among others, yes. Basically, it changes how the automated nodeid is
computed. Clearly, that shouldn't be done unnecessarily. And also,
pacemaker should cope with changing nodeids; I thought recent (I forgot
when exactly) pacemaker updates fixed this. It can be a bit messy at
times.

> BTW: The manual page does not says that "nodeid" has to be a positive 32-bit
> 2-complement; the page just says it's a 32-bit number...

For corosync, it doesn't matter, this is a limitation actually coming
from the DLM in-kernel. Isn't that nice. ;-)


Regards,
Lars

--
Architect Storage/HA
SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Jennifer Guild, Dilip Upmanyu, Graham Norton, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde

_______________________________________________
Linux-HA mailing list
Linux-HA@lists.linux-ha.org
http://lists.linux-ha.org/mailman/listinfo/linux-ha
See also: http://linux-ha.org/ReportingProblems