On 2015-01-30T14:57:29, Ulrich Windl <ulrich.wi...@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
