Hi all,
The just-released Pacemaker 2.0.0 and 1.1.19 releases have an issue
when a Pacemaker Remote node is upgraded before the cluster nodes.
Pacemaker 2.0.0 contains a fix (also backported to 1.1.19) for the
longstanding issue of "crm_node -n" getting the wrong name when run on
the command
>>> Philipp Achmüller schrieb am 16.07.2018 um
14:09 in
Nachricht :
> Hi,
>
>> Von: "Ulrich Windl"
>> An:
>> Datum: 16.07.2018 13:46
>> Betreff: [ClusterLabs] Antw: Antw: Antwort: Antw: corosync/dlm fencing?
>> Gesendet von: "Users"
>>
>> Hi again!
>>
>> Oh, I missed "...maintenance i would
Hi,
> Von: "Ulrich Windl"
> An:
> Datum: 16.07.2018 13:46
> Betreff: [ClusterLabs] Antw: Antw: Antwort: Antw: corosync/dlm fencing?
> Gesendet von: "Users"
>
> Hi again!
>
> Oh, I missed "...maintenance i would like to standby 1 or 2 nodes from
> "sitea""...
>
Yes - sorry for tons of logs
Hi again!
Oh, I missed "...maintenance i would like to standby 1 or 2 nodes from
"sitea""...
I think some time ago I had asked about the same thing for SLES11, and the
answer was that with some configurations a standby is not possible (I thought
it was related to OCFS2, but mybe it was cLVM or
>>> Philipp Achmüller schrieb am 16.07.2018 um
11:44 in
Nachricht :
> hi!
>
> Thank you for comment.
> Unfortunatly it is not obvious for me - the "grep fence" is attached in my
> original message.
Hi!
OK, seems I missed finding the needle in all the hay...
Anyway I think the problem is
hi!
Thank you for comment.
Unfortunatly it is not obvious for me - the "grep fence" is attached in my
original message.
i searched older logs with activated dubug information for dlm: - this is
the sequence from syslog (from another timeframe):
---
Node: siteb-2 (DC):
Hi!
I don't run SLES 12, but in SLES 11 some RAs tried to unload kernel modules
during stop, and when you had installed kernel updates before, the operation
failed, and the cluster paniced (i.e.: started to fence the node). In your case
it should be obvious from the logs why the cluster wants to
