<div dir="ltr"><div>Hi Riccardo,</div><div><br></div><div>As I see you have already handled the issue, but I would recommend using static node names</div><div>in the corosync.conf instead of reference to hostname. I did so years ago and now I have no issues</div><div>with hostname changes.</div><div><br></div><div>e.g.:</div><div>node {<br> ring0_addr: 1.1.1.1<br> name: my.node<br> nodeid: 123456<br> }<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Oct 1, 2020 at 10:10 PM Riccardo Manfrin <<a href="mailto:riccardo.manfrin@athonet.com">riccardo.manfrin@athonet.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Thank you for your suggestion Ken; I'm indeed on Centos7, but using<br>
<br>
hostnamectl set-hostname newHostname<br>
<br>
in place of<br>
<br>
hostname -f /etc/hostname<br>
<br>
didn't have any beneficial effect. As soon as I powered off one of the<br>
two nodes, the other one took the old hostnames back and drifted out of<br>
sync.<br>
<br>
The only way of doing this in the end was<br>
<br>
1. rebooting the machine (close in time so that the first new corosync<br>
instance coming up never ever sees the old instance from the other node,<br>
or it gets the old hostnames again)<br>
<br>
2. killing pacemakerd and corosync (and letting systemd bring them on up<br>
again).<br>
<br>
This second method appears to be the cleanest and more robust, and has<br>
the advantage that while primitives/services are unsupervised, they are<br>
not reloaded.<br>
<br>
I hope this can be of help to someone although I tend to think that my<br>
case was really a rare beast not to be seen around.<br>
<br>
R<br>
<br>
On 01/10/20 16:41, Ken Gaillot wrote:<br>
> Does "uname -n" also revert?<br>
><br>
> It looks like you're using RHEL 7 or a derivative -- if so, use<br>
> hostnamectl to change the host name. That will make sure it's updated<br>
> in the right places.<br>
________________________________<br>
<br>
Riccardo Manfrin<br>
R&D DEPARTMENT<br>
Web<<a href="https://www.athonet.com/" rel="noreferrer" target="_blank">https://www.athonet.com/</a>> | LinkedIn<<a href="https://www.linkedin.com/company/athonet/" rel="noreferrer" target="_blank">https://www.linkedin.com/company/athonet/</a>> t +39 (0)444 750045<br>
e <a href="mailto:riccardo.manfrin@athonet.com" target="_blank">riccardo.manfrin@athonet.com</a><mailto:<a href="mailto:riccardo.manfrin@athonet.com" target="_blank">riccardo.manfrin@athonet.com</a>><br>
[<a href="https://www.athonet.com/signature/logo_athonet.png" rel="noreferrer" target="_blank">https://www.athonet.com/signature/logo_athonet.png</a>]<<a href="https://www.athonet.com/" rel="noreferrer" target="_blank">https://www.athonet.com/</a>><br>
ATHONET | Via Cà del Luogo, 6/8 - 36050 Bolzano Vicentino (VI) Italy<br>
This email and any attachments are confidential and intended solely for the use of the intended recipient. If you are not the named addressee, please be aware that you shall not distribute, copy, use or disclose this email. If you have received this email by error, please notify us immediately and delete this email from your system. Email transmission cannot be guaranteed to be secured or error-free or not to contain viruses. Athonet S.r.l. processes any personal data exchanged in email correspondence in accordance with EU Reg. 679/2016 (GDPR) - you may find here the privacy policy with information on such processing and your rights. Any views or opinions presented in this email are solely those of the sender and do not necessarily represent those of Athonet S.r.l.<br>
_______________________________________________<br>
Manage your subscription:<br>
<a href="https://lists.clusterlabs.org/mailman/listinfo/users" rel="noreferrer" target="_blank">https://lists.clusterlabs.org/mailman/listinfo/users</a><br>
<br>
ClusterLabs home: <a href="https://www.clusterlabs.org/" rel="noreferrer" target="_blank">https://www.clusterlabs.org/</a><br>
</blockquote></div></div>