[SOLVED] Edit .members file

[herseitan]

Hi everyone !!
Someone know if is possible (and how) to edit ".members" file in the "/etc/pve/" folder ??

I will appreciate your help.

Regards !!

 

[t.lamprecht]

Hi,

Not directly, it's a virtual file that shows the current cluster member, which is derived from which nodes you joined the cluster and if the cluster is healthy. So you can indirectly change its content by joining or making nodes leave.

https://pve.proxmox.com/pve-docs/chapter-pmxcfs.html#_special_status_files_for_debugging_json
https://pve.proxmox.com/pve-docs/chapter-pvecm.html#pvecm_join_node_to_cluster

So, why would you want to edit that, i.e., what's your actual issue?

 

[herseitan]

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 !!

 

[t.lamprecht]

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.

 

[herseitan]

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 !!

 

[herseitan]

Seems like all time the issue was the hosts file.
Thanks so much, cluster is working perfectly now.

 

[t.lamprecht]

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.