Migrating servers - IP address change

Hi, I have an existing virtualmin setup and want to move to another hosting provider - so need to move the whole lot over. I read on your website that it is simply a matter of doing a full backup from OLD hosting - installing Virtualmin fresh on NEW hosting and then restoring data from OLD hosting backup to NEW hosting. Easy enough but... what about the IP addresses? Obviously, these will all change. Can you please advise me the best way to change them over to the new IP addresses? I have very low DNS records (five minutes) including MX records, so can change where all the domains are pointing too pretty quickly with little down time. However, i can't see a way of changing the IP addresses easily, except by doing them one by one? thanks ! steve



Howdy -- there are migration instructions here that can assist with how to migrate from one server to another:


Part of the process there is importing the backups into the new server. By default, performing that import will change the IP address used by the domains to the default shared IP on your new server.

That, in theory, should be what most of those domains would be using.

Then, if any of the domains are supposed to be on a private IP, you could manually fix those by going into Server Configuration -> Change IP Address, and setting the new IP there.

How does that sound, will that do what you're after?

thank you - sounds like it should work out ok then. regards steve

Hi, just tried this today - and it completely stuffed up !!

There are two issues - first, the old server:

32 bit - Centos 6.0

new server:

64 bit - Centos 6.3

How can I migrate safely please? I did the backup/restore and it kernel panicked the new server and it cost me $166 to have it reloaded again - so don't want to make the mistake again !!

regards steve

It's actually quite common to migrate from one distro to another, or one architecture to another, using Virtualmin's backup and restore.

If you receive a kernel panic -- that suggests either a hardware problem, a resource problem, or a kernel bug.

You shouldn't have to reload the OS though, you should just have to reboot the server and then continue the process.

If you continue seeing kernel panics, there's some sort of underlying problem with the setup there.

As for diagnosing the issue --

You may want to review /var/log/messages and /var/log/secure around the time of the problem to see if the kernel generated any errors. You can also review /var/log/dmesg for any problems.

Also, are you using a dedicated server, or a VPS?

Lastly, how much RAM is on your system? You can determine that with "free -m".

thanks for the reply. It is a dedicated server. I have just had the fresh rebuild and done:

yum upgrade yum update reboot

downloaded and installed Virtualmin installed google analytics installed postgrey (as was using this on my old server) ran web interface through web min.. and ran wizard (clams and spam failed, but that happened last time and was ok on reboot) rebooted server

all is running perfectly. I have now gone to the old server and doing another full backup. So, when I RESTORE to the new server, should I be restoring ALL the features? Maybe this is what broke it before?

regards steve

I have now gone to the old server and doing another full backup. So, when I RESTORE to the new server, should I be restoring ALL the features? Maybe this is what broke it before?

Well, again, the problem you saw was not related to anything you did or didn't do during the restore... a kernel panic is caused by one of three things:

  1. A hardware problem

  2. A resource problem (ie, too little RAM -- but on a dedicated server that shouldn't be a problem)

  3. A kernel bug

If you'd like to track down the cause of the kernel panic, you could try looking at the logs that I mentioned above, as it's possible the kernel generated some debugging information prior to the panic.

Outside of that -- there's nothing you could do differently during the restore -- software doesn't cause a kernel panic... only hardware problems, resource problems, and kernel bugs can cause a kernel to panic.

You don't need to reload the OS if that happens again... though if it happens repeatedly that implies a pretty big problem with the underlying setup.

Also, I'd recommend making sure you have the latest kernel available to CentOS (which you can do by running a "yum update"). In the case of a kernel bug, you'd definitely want to be using the latest kernel.