Skip to main content

One thing that I find really useful if you’re moving a small VM for a small customer that doesn’t have a VCenter to a new Vsphere host is to just simply connect the the two ESXi hosts in Veeam:

  1. Add both hosts in the Virtual Infrastructure
  2. Create a replication job between the old host and the new host
  3. If it runs rather slow let it run for a few days. 
  4. Determine a small outage window where you’ll have the customer stop accessing data on the old host.  Do one more replication job.
  5. Shut the old VM down in the old host
  6. Power on the new server on the new host.

It’s important to not use the replica_ prefix or suffix just for the sake of simplicity. 

A lot of times focus is on larger customers and how to vmotion this or that but sometimes it’s nice to think about how small customers can be served too.  Using Veeam for that is a life saver.

I used Veeam for that in my last job more then a few times. It’s really works! :)


Great post, @AndySmall! One note, if you follow steps 4-6, though you risk having some small data loss as data could have changed between the last replication run and the shutdown. Ideally, you would run another (very quick) replication run after the shutdown. A replacement to 4-6, could be to use the Planned Failover feature: https://helpcenter.veeam.com/docs/backup/vsphere/planned_failover.html?ver=100

 

Depending on the needs, you don’t even need to set up a replication job. The quick migration feature is very nice: https://helpcenter.veeam.com/docs/backup/vsphere/quick_migration.html?ver=100


Great post, @AndySmall! One note, if you follow steps 4-6, though you risk having some small data loss as data could have changed between the last replication run and the shutdown. Ideally, you would run another (very quick) replication run after the shutdown. A replacement to 4-6, could be to use the Planned Failover feature: https://helpcenter.veeam.com/docs/backup/vsphere/planned_failover.html?ver=100

 

Depending on the needs, you don’t even need to set up a replication job. The quick migration feature is very nice: https://helpcenter.veeam.com/docs/backup/vsphere/quick_migration.html?ver=100

Came here to say planned failover since we’re talking about a small outage window anyway Veeam can automate this task for you. The benefit to using planned failover + permanent failover is that if the job is running on a schedule (for example you were continuously rolling up the changes to keep the final cut over small during your maintenance window), you wouldn’t have Veeam attempt to replicate anymore whilst the failover is in progress and once permanently failed over it would be added to the exclusions.

 

+1 For Planned Failover


Great idea! … Storage vMotion for poor man :wink:


Great post, @AndySmall! One note, if you follow steps 4-6, though you risk having some small data loss as data could have changed between the last replication run and the shutdown. Ideally, you would run another (very quick) replication run after the shutdown. A replacement to 4-6, could be to use the Planned Failover feature: https://helpcenter.veeam.com/docs/backup/vsphere/planned_failover.html?ver=100

 

Depending on the needs, you don’t even need to set up a replication job. The quick migration feature is very nice: https://helpcenter.veeam.com/docs/backup/vsphere/quick_migration.html?ver=100

well that’s awesome! Thanks for the additional tip!


@wesmrt : great one !


I have long been advocating that Veeam replication is a great way to move to a new VMware design. This can be the standalone host → vSphere cluster scenario as @AndySmall outlines, but also existing cluster to existing cluster.

In the existing cluster to (different/new) existing cluster scenario that is unique is that it gives you the ability to ‘leave behind bad design decisions of the past’. Trust me, we all have them. Storage, networking, security, etc. Old cluster designs simply upgraded on top of never change some of the root problems. Migrating to a new one with Veeam replicas is an easy way to do it.

I like to:

Set up replication job (Full first run)

Run the replication job again (incremental run)

Shutdown original/source

Run the replication job again (incremental run)

Fail over.

This way there is no data loss!


Comment