This is the first in a series of posts in the “Easy Mode” series
I thought I would write this up as a super easy basic guide to an almost no-effort method of migrating a KVM VPS from one host to another without having to worry about any minor changes in software stacks that could cause your backup and restore to fail or not restore as expected.
As a host one of the unfortunate realities is that sometimes it is just necessary to have migrations either due to end of life of an OS major version or impending hardware failure etc and on the rare occasion you need people to migrate their own server, this usually results in a 10% panic rate and a desperate cry for help.
With all that in mind I thought I would illustrate possibly one of the most simple server migration methods possible, I have done this based on KVM to KVM as that is likely to be the most common method however this method should also work for Xen HVM to Xen HVM or KVM to Xen HVM or Xen HVM to KVM and finally VMware to VMware should also work fine.
I can’t cover the huge amount of different control panels and access methods out there but all that I have used either have access to an ISO mount or a rescue mode so it should be easy for you to use this guide as long as your host’s control panel provides at least an ISO mount option or a rescue mode.
In this example, I have used a KVM VPS on a host that uses SolusVM and migrated it to a host that uses Virtualizor.
Requirements and additional info before we get started.
- The destination VPS should have the same size hard disk (bigger is fine).
- This will only go as fast as the link between the 2 locations, latency is a huge factor, moving a 50GB Disk image from India to New York is no fun.
- Some attention to detail is required, it is possible to lose your data if you mess up the commands.
- If the destination control panel does not provide a ‘reconfigure networking’ button or a serial console/VNC option you can use to reconfigure networking yourself you may want to consider configuring but not activating the network settings for the destination VPS on the source prior to shutdown, SolusVM, however, will do this for you and in some cases depending on the Hosts configuration options in Virtualizor it will also.
- Source VPS, in this case, was at Inception Hosting – London, the destination VPS was with Nexus Bytes – New York
First of all, I created a quick KVM VPS as the source on the SolusVM based host, installed apache2 and slightly modified the test page which you can see loading on the source IP:
Then I shut down the Source VPS and put both the source and destination VPS into rescue mode.
For SolusVM (Source):
For Virtualizor (Destination):
note: I noticed virtualizer has a tendency to just lock out all options even those for coming out of rescue mode when you do this which is resolved by simply refreshing the page, don’t worry it does not resubmit the action
Now you should have both the source and destination in rescue mode and you should be able to login to both over ssh:
SolusVM VPS (Source)
Virtualizor VPS (Destination)
Next, you need to examine your disks to make sure you get the right one, the rescue modes will create a ramdisk so what was vda or sda on your VPS when it was running may not be now, this is the part you need to be sure you get correct, I have shown a side by side below using
fdisk -l to check which disk I want to migrate to which disk on the other end.
From the image above we can see that the 5GiB disk is the one I want
/dev/vda because I know my source disk is 5GiB and on the destination side I can see that it is actually
/dev/vdb I want to copy the disk to, the 10 GiB disk. It is very important that you check this before going any further as it could well be different.
Because we now know I want to copy
vda on the source to
vdb on the destination we can structure the command to do this.
dd if=/dev/vda bs=32M status=progress | ssh [email protected] "dd of=/dev/vdb"
let us break this down so it is better understood as there is nothing worse than knowing which buttons to press to achieve a goal, but having no idea why they work, or what they actually do:
- dd – Short for “data duplicator” a common commend used for copying or duplicating data.
- if=/dev/vda – The input or what we are reading, in this case, the entire virtual hard disk image
- bs=32M – BYTES, the number of BYTES to read per block when copying, you can set this yourself, I have found 32M is a good average.
- status=progress – This shows the progress of the copy, it has a very small overhead but without it you get nothing in terms of a progress indicator
- | – The pipe, in very simple terms, lets you pass the result of one command or set of commands to the next
- ssh [email protected] – Because this is after the pipe | it takes what was done before and sends it over an ssh session as root to the destination IP 18.104.22.168 (fake)
- “dd of=/dev/vdb” – Finally the instruction on what to do at the other side which is to use dd “data duplicator” to write the blocks it is receiving over ssh to
Once that command is issued you will see something like this:
And when it completes you will see:
As we can see that took 634 seconds or a little over 10 minutes to complete and now the disk image on the destination should be identical to the source.
The next step is to cancel rescue mode on the destination via the control panel and then boot the destination VPS, going to the new IP address once it is finished booting shows that it was a success as the same page loads on the new IP:
If your destination VPS has a bigger disk size than the source you will not instantly gain the extra space by following the above process, you will need to either expand your partitions or extend your logical volume if using LVM, that however is beyond the scope of this particular tutorial but if you are also looking for easy mode for that then just boot the VPS with a GParted ISO or a rescue cd that contains GParted which will give you a simple UI to expand your partitions or look up vgextend and lvextend if using LVM.
If having read this you discover that your host does not have a built-in rescue mode then I would suggest requesting they supply a SystemRescueCd ISO (Also contains GParted) https://www.system-rescue-cd.org/ so you can mount it and boot into rescue mode.