[SOLVED] Edit .members file

herseitan

New Member
Apr 12, 2023
4
0
1
Hi everyone !!
Someone know if is possible (and how) to edit ".members" file in the "/etc/pve/" folder ??

I will appreciate your help.

Regards !!
 
Last edited:
Thanks for your reply t.lamprecht.

I have a "Network" issue with my cluster, when i created the cluster I select the Cluster Network with an interface in a range 192.X.X.X, both nodes has been joined to the cluster (apparently) fine but for some reason that I dont know one of the nodes takes a network interface with another range.

When I trying to move a VM from host "56" to host "52" I dont have any issue, work perfect.
But when i tried to move from "52" to "56" i have an error caused by the "different" network

TASK ERROR: command '/usr/bin/ssh -e none -o 'BatchMode=yes' -o 'HostKeyAlias=56' root@38.X.X.X pvecm mtunnel -migration_network 192.168.X.X/24 -get_migration_ip' failed: exit code 255

So ".members" file have the wrong IP address, that's why I want to edit that file.

Thanks again for your reply.

Regards !!
 

Attachments

  • corosync.png
    corosync.png
    55.2 KB · Views: 23
  • members.png
    members.png
    37.8 KB · Views: 19
  • members_info.png
    members_info.png
    21.1 KB · Views: 19
The IP shown in .members is the one the node name resolves too, and if you don't have an internal DNS infrastructure this is most likely coming from /etc/hosts on the affected node itself.
So, if you edit that (directly or via the API) to its IP from the 192.168.x.y/z network and reboot the node you should be good again.

For the migration network specific issue you can also override the migration network in the Web UI under Datacenter -> Options -> Migration Settings, if you set the 192.168.x.y/z network explicitly there, the nodes should avoid the autodetection, and it should work again.

Correcting the IP resolution of the nodename makes sense nonetheless, as if the node isn't reachable by the other node via that (or takes an inefficient route) you'll always have trouble for some action in a cluster.
 
The IP shown in .members is the one the node name resolves too, and if you don't have an internal DNS infrastructure this is most likely coming from /etc/hosts on the affected node itself.
So, if you edit that (directly or via the API) to its IP from the 192.168.x.y/z network and reboot the node you should be good again.
Understood, it seems logical to me ;)
I will try and i will return with the feedback.

Thanks a lot for your help !!
 
Seems like all time the issue was the hosts file.
Thanks so much, cluster is working perfectly now.

:)
 

Attachments

  • members_1.png
    members_1.png
    8.3 KB · Views: 34
Great that you got it to work! As thread creator you could set the "Solved" prefix for this thread, using the Edit Thread button above your initial post at the right.
 
I recently ran into the same issue (Proxmox was guessing the wrong IP address for my nodes, which caused
Connection error 595: No route to host errors in the web UI). I also fixed it by editing /etc/hosts.

I didn't want to reboot my nodes; but it looks like merely restarting pve-cluster was enough (systemctl restart pve-cluster), so I'm leaving that comment in case that helps anyone else.
 
I can echo this, sort of.

I had a cluster configured (2 nodes) with dedicated 10Gb Data network and 10Gb Cluster/Storage network.

I did have to change IP's on one node, which removed an old IP 172.16.10.11 (data) from node1 leaving it with only one IP on the correct interface 172.16.10.12 (data) and one IP 172.16.101.11 (Cluster/Storage ), since I had configured the node with the data network initially on the wrong interface (regular internal 1Gb NIC instead of the proper 10Gb nic), I changed the "Cluster --> Options --> Migration Settings" to the Cluster/Storage Network, ensure /etc/hosts was updated and restarted the cluster with "systemctl restart pve-cluster" and it would migrate using the proper Cluster/Storage Network leaving the data NIC untouched for the guests regular workload, migrating in near real-time now.

Thanks for the walkthrough, this one was a bugger to ID and solve.