Last updated on Monday 28th of February 2022 08:52:48 PM

Free ©VMWare ©ESXi live virtual machine migration

How to migrate ©VMWare ©ESXi virtual machines to a new server locally or over IP

©XSIBackup allows to easily live migrate VMs from one ©ESXi server to another. You can always achieve that goal by sharing some datastore, but that is not possible in every situation.

What if you had to migrate some VMs from one ©ESXi internet host?

Luckily ©XSIBackup has the ability to differentially replicate data over IP, it is even able to make use of CBT technology to know the blocks that have changed since last backup. This feature will allow you to easily migrate your virtual machines over some WAN connection.

First of all you have to download the latest package from the product page

We offer totally functional versions of our software during some days since the date of release. This will allow you to use our software to easily live migrate your VMs without a license.

We are sure you will find our tool a must have after testing it and its price won't be a drawback for you.

Free ESXi virtual machine migration

You are probably thinking: "well, I can achieve that by using Rsync". You are right, nonetheless using Rsync to migrate a VM is subject to some inconveniences that you can't ignore.

If your VM is an SME production server that can be stopped during the night or even during a whole weekend, then any standard tool such as Rsync or even SCP will do it. You just depend on the opportunity window being big enough to complete the task.

Nonetheless, if you need to migrate a VM which is fairly big and can't be stopped for long enough to complete a full transfer of the -flat.vmdk files, then you will need a different approach.

Rsync is a great tool, we love it, still it can't cope with some common situations when migrating VMs. Rsync's delta algorithm is extremely thorough. It can take a lot of time to calculate the checksums of a multi terabyte VM, much more than a whole night or even a full weekend.

Here is where CBT or Changed Block Tracking technology comes in handy.

CBT allows to differentially and consistently transfer the differential data between replication cycles without having to go through a full delta checksum comparison. This way you can take the time to transfer the -flat.vmdk files in the background whatever time it takes, to then perform a last pass only on the remaining changed blocks since last cycle, which usually takes just the time to transfer some MBs.

Another important aspect of CBT is that once you have transferred the bulk of the data, you can run it as many times as you want. The shortest the time you take in between replication cycles, the smaller the remaining CBT data to transfer will be. You can even run it from some previous differential point, so that you can make sure that you copy any eventually missing block.

©XSIBackup offers you the tools to perform the migration, there may be other tasks associated with that migration, like redirecting users to a new IP.

Let's take a very common scenario: you have some HTTP and DB virtualized servers running as guests in some ©ESXi host and you need to migrate them to a new server without any downtime.

VM migration scenario

There will be data changing every few days or weeks in the Apache server, namely: your website content. The activity logs will be changing continually, you may treat that data differently, as it's not essential to run your web server before the public. On the other side there will be data changing every few seconds: the database server, especially if you receive some kind of data through it, like contact forms, forum posts or some other kind of user interactions.

So, in this kind of scenario the plan is obvious: transfer the bulk of the data in the HTTP and database server. Perform one or more last differential replicas from the production database server and optionally from the HTTP server, as it may contain data associated to the DB, like some uploaded images in your web forum per instance.

Now set your database server to read-only mode right after the last differential backup and redirect your traffic to the new website as fast as possible. This should all be scripted and tested before actually performing the migration, so that you can be sure your users don't notice any glitch in the services you are providing.

That is the main general idea behind what the migration of such a system should be. There will be some details that need to be addressed though:

Quiescing the snasphot to migrate an active database

We have covered this topic many times before: quiescing. Database servers require a way to make sure that data written to the database server is consistent, that is: that no data is written partially, so that your DB records contain full meaningful data.

Depending on the type of database server that you are running, you may be able to directly quiesce the server without any further ado, or you may need to install additional software and configure services to make it possible. You may even have some old database software that just can't be directly quiesced. If the latter is your case, you can always just make it read-only during the last differential backup step, stop it, turn on some kind of SQL synchronization, etc..., we won't delve ino it now.

We will assume you can just quiesce the database virtual machine and that adding --quiesce to the replica job will just do it. This will leave you with hopefully just some seconds during which you must not allow writes to the database. It is the time it will take to redirect the traffic to the new DB server. If you do it right this time can become very short, just the time for the last replica job to complete. Using CBT here is crucial for the migration to be as seamless as possible.

Redirecting the traffic to the new host

There are multiple techniques that you can use to redirect your traffic, we recommend that you combine all of them to make the user experience as agnostic to the migration process as possible. If you do it right nobody will notice anything.

First of all, set your mirrored HTTP application to connect to the new database server, so that when you redirect the traffic to it it will be connected to the new DB server. Set your database server to read-only mode right before the final replication job on the production server. It will not allow writes (UPDATE & INSERT statements), they are less frequent than SELECTs and the downtime will be minimal though. At this stage you can also utilize other techniques at the application level, like delayed SQL statements or an SQL proxy, we'll leave that as it's not directly related to virtualization.

Once the last --replica job has completed, it should not last more than some seconds even on multi terabyte VMs if you use CBT, just switch the replicated database server on (the HTTP server should already be on by now) and set your HTTP server to perform an HTTP level redirect to the new HTTP server. You should have done the DNS level redirection before, it will take some hours to complete, during this time it will be the HTTP redirection what will keep the traffic coming to your new website. Once the DNS transfer is complete, you can turn your old HTTP and database servers off.