Best way to migrate VMs from old pool to new?

olivierlambert

Note this is done almost automagically via our warm migration option (doing the same but integrated)

DustinB

@Danp said in Best way to migrate VMs from old pool to new?:

I would setup a Continuous Replication backup job to create a duplicate VM on the new storage repository. When you are ready to perform the cutover, shutdown the original VM, perform one final run of the CR job, and then start the new VM on the new pool.

This is exactly what I did years ago on another environment that I managed. Worked great and was seemless.

ediazcomellas

@olivierlambert There is a slight but important difference: with the replication you still have the VM in the old pool as a failsafe. I just love warm migrations between clusters. They look like magic to me BUT precisely that magic feeling makes me worry about "what happens if something goes wrong?"

It would be super cool to be able to check "leave the old machine powered off, I will delete it myself" when doing a warm migration between clusters.

olivierlambert

In that case, use replication, it's exactly what you need. With warm, you can always "warm back" to the original machine though.

ediazcomellas

@olivierlambert That is what I do right now. It would be very convenient to have warm migration without deleting the VM disk and configuration in the old cluster, though, as I would have the convenience of warm migration (don't need to shutdown, all actions automated) and the peace of mind that if something goes wrong, I can always start the VM again in the old cluster.

Thanks for the answer!

KPS

@ediazcomellas
Did I miss anything, or: Why don't you just live-migrate between the hosts? Did you change the CPU manufacturer?

If the VMs size is below 1TB, that should work fine, but - of course - the VM is removed from the source.

ediazcomellas

@KPS live/warm migration between clusters is what we were discussing here. Yes, we do it routinely and it is a fantastic feature.

We have some VMs with more than 1 and 2 TBs of storage, so that takes ages. In that case, it is easier to assume some downtime and follow the continuous replication strategy, with the last copy done while the VM is powered off. The only advantage of this strategy over the live migration is that you retain a copy of the VM in the old cluster.

The ability to do a live migration but retain a copy of the VM in the old cluster, just in case, would be greatly appreciated. Best of both worlds.