Migrating proxmox cluster node to a different network
I'll walk through the process of moving a Proxmox cluster node from one network to another, as part of my larger effort to bring order to the chaos, ensuring the cluster remains operational throughout the transition.
A big shootout to Bubbagump210, who wrote a post without which I would never be able to do this migration.
My home network is a mess. Like in many ad-hoc setups, it has grown piece by piece over the past three years. This gradual expansion has led to a less-than-optimal setup: VLANs that are poorly segmented, inconsistent IP address spaces, and consequently, firewall rules that are hard to manage and chaotic. It’s time to reorganize everything, starting with a consistent layout for VLANs and IP addresses, beginning with my Proxmox infrastructure.
I'll walk through the process of moving a Proxmox cluster node from one network to another, as part of my larger effort to bring order to the chaos, ensuring the cluster remains operational throughout the transition.
Migrating a Proxmox cluster node from one network to another can seem daunting, as it involves reconfiguring the node’s IP address without breaking the cluster. Fortunately, following the correct steps will allow you to achieve this with minimal downtime and risk of losing node connectivity.
Here is a step-by-step guide based on community advice and best practices for Proxmox clusters.
- Edit corosync configuration:
- On the node that you want to migrate, open the file
/etc/pve/corosync.conf
. - Update the IP address for that node.
- Increment the
config_version
number. This is crucial because it signals the cluster to propagate the updated configuration across all nodes. - Save and close the file.
- On the node that you want to migrate, open the file
- Update network configuration:
- Next, edit
/etc/network/interfaces
or modify the network configuration from the web ui in order to assign the new IP address to the correct network interface (e.g.,vmbr0
). - Make sure to also update
/etc/hosts
with the new IP address, ensuring that the node can resolve itself and other nodes correctly.
- Next, edit
- Restart network interface:
After modifying the network configuration, restart the network interface to apply the changes. You can do this with the following command:ifdown vmbr0; ifup vmbr0
Assuming that the network interface is called vmbr0. If it is not your case, replacevmbr0
with the correct interface name. - Restart cluster services:
On the node you are moving, restart the Corosync service and the Proxmox cluster service to apply the changes:systemctl restart corosync
systemctl restart pve-cluster
This will reinitialize the node’s participation in the cluster with its new IP. - Check cluster status:
After restarting the services, check the status of the cluster to ensure that the node is properly connected and that quorum is maintained:pvecm status
If everything is configured correctly, all nodes should appear, and the cluster should have good quorum. - Apply changes across all nodes:
Once the node is up and running with its new IP, you need to restart the Corosync service on all other cluster nodes. This ensures they recognize the node with its new address:systemctl restart corosync
Check the status of the cluster on each node to ensure all nodes can communicate.
Additional notes:
- Please note that
/etc/issue
will contain the text banner still pointing at the old ip address. - Sometimes the VM(s) or containers may lose network connectivity during the process.
- A second NIC would make the migration process much smoother: at the cost of a slightly longer migration, you can setup another temporary interface which will be not migrated in order to have an always reachable pve node to avoid being cut out from the machine and then having to physically interact with it. In my case, having already 2 network interfaces available with attached cables make me follow the entire procedure via ssh/web.
By following these steps, you can successfully migrate a Proxmox cluster node to a new network without permanently disrupting cluster operations. Make sure to test connectivity between nodes after each step and verify that the new IP configurations are working properly.