It is indeed a bit difficult because the node names are all over in
the configuration, especially the logical volumes used for the disks
contain the node name, etc.
You have described the simple solution, which requires a bit of work
(migrate everything off one node, remove it from the cluster, rename
it, re-add it to the cluster, repeat with next node, etc.
The other solution is to stop the daemons and edit the configuration
files by hand but you must be extra careful with that (make backups,
make sure nothing else is writing to the config files, etc.)
> For the vm, it should not be an issue, because I can rename them in
> ganeti.
Correct.
--
olive
Yes, it will be enough. Ganeti has no issues with multiple subnets.
> > The other solution is to stop the daemons and edit the configuration
> > files by hand but you must be extra careful with that (make backups,
> > make sure nothing else is writing to the config files, etc.)
> Where are all these config files located ? Are they only plain-text
> files ?
/var/lib/ganeti/, and yes they are plain-text files (in JSON format).
> I guess I must edit then on the master node, then propagate them on
> other nodes by hands (ganeti-cluster redist-conf will works ? )
Yes.
regards,
iustin
While the master daemon is stopped, you will actually need to scp the
files by hand. If the files are not in sync, ganeti-masterd does not
start.
--
olive
Ah yes, for renaming the nodes indeed. Alternatively one can force startup and then run redist-conf.
iustin
ssh $ganeti_master
old=old_node_name
new=new_node_name
cd /var/lib/ganeti/
/etc/init.d/ganeti stop
sed -i -e "s/$old/$new/g" config.data ssconf_*
/etc/init.d/ganeti start
gnt-node list | grep -E "$old|$new"
As I said, I used this procedure several times safely on a live production environment.