[PVE-User] pve-firewall, clustering and HA gone bad

[Thomas Lamprecht]

On 6/13/19 3:29 PM, Horace wrote:
> Should this stuff be in 'help' documentation ?

The thing with the resolved ringX_ addresses?

Hmm, it would not hurt if something regarding this is written there.
But it isn't as black and white, and often depends a lot on the
preferences of the admin(s) and their setup/environment.

Some hints could probably given, especially for a IPv6 addition/switch,
as the getaddrinfo preference of IPv6 over IPv4 if both are configured
has often bitten people (see /etc/gai.conf , man gai.conf), not only with
clustering or PVE.

A few other hints could probably thrown into that too..
Stefan (CCd), would you be willing to take a look at this and expand the
"Cluster Network" section from the pvecm chapter in pve-docs a bit
regarding this? That'd be great.

> 
> On 6/13/19 12:29 PM, Thomas Lamprecht wrote:
>> On 6/13/19 1:30 PM, Mark Schouten wrote:
>>> On Thu, Jun 13, 2019 at 12:34:28PM +0200, Thomas Lamprecht wrote:
>>>> Hi,
>>>> Do your ringX_addr in corosync.conf use the hostnames or the resolved
>>>> addresses? As with nodes added on newer PVE (at least 5.1, IIRC) we try
>>>> to resolve the nodename and use the resolved address to exactly avoid
>>>> such issues. If it don't uses that I recommend changing that instead
>>>> of the all nodes in al /etc/hosts approach.
>>> It has the hostnames. It's a cluster upgraded from 4.2 up to current.
>> OK, I suggest that you change that to the resolved IPs and add a "name"
>> property, if not already there (at the moment not to sure when I added
>> the "name" per-default to the config, it was sometime in a 4.x release)
>> IOW, the config's "nodelist" section should look something like:
>>
>> ...
>> nodelist {
>>    node {
>>      name: prod1
>>      nodeid: 1
>>      quorum_votes: 1
>>      ring0_addr: 192.168.30.75
>>    }
>>    node {
>>      name: prod2
>>      nodeid: 2
>>      quorum_votes: 1
>>      ring0_addr: 192.168.30.76
>>    }
>>    ...
>> }
>>
>> As said in the previous reply, that should avoid most issues of this kind,
>> and avoid the need for the /etc/host stuff on all hosts.
>>