Using Veeam replication to Migrate Datacenter

[foggy]

Evan, replication jobs is what can really help to perform such a migration.

[collinp]

Is it possible to use Veeam VM Replication as a way to migrate VM's to a new Hyper-v cluster permanently for a one time replication? I don't want to setup a replication relationship between a primary source and destination. I want to do a one-time replication from a source to destination VM and then delete the source VM permanently. These are big 1TB VM's where Hyper-v zero shared migrations fail. I also don't want to risk doing a Veeam instant vm recovery due to performance implications of running from the slow backup storage during the migration.

Collin

[foggy]

Yes, replication is the way to go in this case. Perform permanent failover after replication and once confirming that everything works properly, remove the source VM.

[lukeup]

Hello,

What is the best practice to migrate an Exchange\SQL server from one ESXi host to another?

The hosts are in different vCentres due to Essentials Licensing. So storage\vMotion is not an option.

If shutting down the VM is not a problem, should I do this and then Quick Migrate or just quick migrate the live VM?

Would it be best to back up and restore instead of using Quick Migrate?

The CPUs are not compatible between the hosts so the VM will shut down. Is this ok with Exchange\SQL server?

There are many options and I am not sure of the best way to achieve this.

Thank You

[foggy]

Luke, you can either use replication or Quick Migration to achieve what you're after. Please review the thread above for more details. Thanks.

[andy51585]

Hi,

I would like to leverage a replication job to move from one physical data center to another. I have currently a replica made on the target vCenter server. I was wondering what the best way is do a "final" replication. Is there a way to in near real time synchronize the last changes to the source VM, bring the destination online, and shut down the source. I was looking at the permanent failover option, but that appears to commit the delta of the target. Is it possible to commit a delta of the source?

[foggy]

Andrew, the best practice is to shut the source VM down, perform final replication of the latest changes, and then failover to the replica VM. This allows to avoid any data loss and provides minimum downtime.

[ssen]

I'm building out a new vSphere cluster that is separate from a standalone esxi 5.5 server we have. For licensing and configuration reasons I cannot add the standalone server to my new cluster. I've been playing with Veeam and I'm not sure whether I should use the backup feature or the replication feature to copy the VMs over. I understand "Quick Migration" is available BUT I need the source VMs to stay up and not turn on once it arrives on the new cluster. I want to copy the running VMs into the new cluster and eventually do a failover when we're ready. I can't run a Quick Migration because the network settings on the new cluster can't accommodate the IPs of the VMs on the standalone server.

My question is, should I be using backup or replication? I dont want any dependencies to the standalone server or Veeam once I migrate everything off.

[veremin]

Hi, take a look at the approach described by Foggy; should do the trick for you. Thanks.

[emilec]

I have some Linux servers running PostgreSQL that I want to move to a new location.

If I wanted to get the databases over in a consistent state could I run a replication job while the servers are on to get the bulk of the data over and then shut them down for a final replication? Would my databases be consistent or should the VMs or PostgreSQL service be off from the start?

[foggy]

To get transaction consistency, you can enable VMware Tools Quiescence in the replication job. But it is a good practice to shut the VM down before replicating the final changes to avoid any data loss.

[coolgod]

Hi..am planning to migrate from ESXi 4.1 to 5.5 not by upgrading the existing ESXi 4.1 but replicating the PROD VMs on ESXi to another ESXi running version 5.5.

please advise me on this.

Also advise me on the stability of ESXi 4.1 and #ESXi 5.5. Should I stay with #ESXi 4.1 ?

[veremin]

Your post has been merged into existing discussion regarding similar matter. Kindly, check the answers provided above. Thanks.

[emilec]

To get transaction consistency, you can enable VMware Tools Quiescence in the replication job. But it is a good practice to shut the VM down before replicating the final changes to avoid any data loss.

So my plan should work then:
1) Replicate running VMs until all the data is at the remote side.
2) Shut down the VMs and run replication again.

[foggy]

Yes, should work.

[marama]

Hi!

ESXi 5.5, Veeam B&R Enterprise+, vmWare Essentials (no vMotion)

We have one host (host1) running production VMs, we have another one (host2) running the replicas, and we have a physical PC running Veeam B&R performing replication but also doing backup and offsite backup copy . There is also an off-site that hosts the backup copy.

We've received a new host (host3) and we need to move ALL the VMs from host1 to host 3 with least possible impact. With least possible impact, I mean not to reseed the offsite host, but also to have the short failover time for production hosts.

The problem is some VMs are rather big (1.5TB) and "quick migration" doesen't work for me because I'd have probably 20 hours downtime for the big VM, right? And with not fix-projected end time (so I can jump in and fix networking).
Another challenge is preserving the MAC address since I have DHCP with reserved IP running on some systems. I will try to switch most of the VMs to static IP, but some will have to remain DHCP.

What I am now trying to do is to have replication migrate the VMs, so I can pre-replicate the big VM, and then just before the permanent-failover I'd shutdown the VM, perform the final (incremental/differential) replication. But the issue here seems to be that the replicated VM is completely new VM, meaning backup and backup copy need to be re-seeded and all the history breaks. My backup jobs handle multiple VMs, so I cannot map single VMs to single backup files.

What would be the best practice for my migration-scenario?

TIA

[foggy]

Your approach with using replication jobs for migration is correct. Regarding backup jobs mapping, if you just re-add corresponding replica VMs into existing backup jobs, you would be able to map the jobs to existing backup files to keep backup history.

Also, if you change the MAC address configuration to Manual, MAC address should be preserved during replication.

[marama]

Thanx Foggy.
I've also received a response from Veeam support (refering to my post):

"
Unfortunately, once the VMs will be replicated to a new host, the history will be lost. So you will need to reconfigure your jobs.
"

so what will it be, backup history lost or not?
It's not so much backup history per se that I need, I would like to avoid having to re-seed the offsite repository.

TIA

EDIT: oh, now I realise the "you will need to reconfigure your jobs" might mean I just need to remap the backup

[foggy]

EDIT: oh, now I realise the "you will need to reconfigure your jobs" might mean I just need to remap the backup

Correct, you would need to map jobs to existing backup files to continue incremental chains.

[marama]

Hi!

Regarding backup jobs mapping, if you just re-add corresponding replica VMs into existing backup jobs, you would be able to map the jobs to existing backup files to keep backup history.

Unfortunatelly, I am still struggling with this. I've tried everything possible to switch backup job source from old host to new host, while keeping the backup "base" - no luck so far. Am still waiting to hear from Veeam Support, but in all my tests I keep getting the line "backup is no longer processed by this job". I guess the VM-replica on the new host has another VMID so the backups treats it as complete different VM, hence cannot make use of existing backup files. Am I doing something wrong, is there a way around this? (am pointing to standalone hosts, not vCenter). I know if I copy the VM files and create VM out of them I get asked if it's VM was moved or copied (at least within the same host), in that case VMID does not change, right? Can I somehow provoke that sort of cloning?
TIA

30.10.2014 22:38:12 :: backup is no longer processed by this job. Make sure this change is intentional.
30.10.2014 22:38:12 :: VM size: 8,0 GB (1,7 GB used)
30.10.2014 22:38:12 :: Changed block tracking is enabled
30.10.2014 22:38:15 :: Preparing next VM for processing
30.10.2014 22:38:15 :: Processing 'backup_delme'
30.10.2014 22:38:17 :: All VMs have been queued for processing
30.10.2014 22:40:31 :: Load: Source 89% > Proxy 92% > Network 25% > Target 0%
30.10.2014 22:40:31 :: Primary bottleneck: Proxy
30.10.2014 22:40:31 :: Job finished at 30.10.2014 22:40:31

[albertwt]

Hi Cor,

You can either use replication or Quick Migration jobs to do that. Please review our Evaluator's Guide for more info.

As to possible tips and tricks for VM migration process, then it would help if we could know a bit more on your environment

Thanks!

So, what's the difference and benefits of using Veeam replication as opposed to using the builtin VMware vSphere replication ?

[foggy]

Unfortunatelly, I am still struggling with this. I've tried everything possible to switch backup job source from old host to new host, while keeping the backup "base" - no luck so far. Am still waiting to hear from Veeam Support, but in all my tests I keep getting the line "backup is no longer processed by this job". I guess the VM-replica on the new host has another VMID so the backups treats it as complete different VM, hence cannot make use of existing backup files. Am I doing something wrong, is there a way around this? (am pointing to standalone hosts, not vCenter).

Have you re-added the replica VMs into jobs?

[foggy]

So, what's the difference and benefits of using Veeam replication as opposed to using the builtin VMware vSphere replication ?

Here's a dedicated topic regarding that, should give you some thoughts: Veeam vs. vSphere Replication

[marama]

I've spent days trying to get this to work (like I was told by Veeam support) and hours talking to the support people... and it turns out it's not possible after all.

This is my cycle:

vSphere Host1 => Backup => Backup copy (offsite)

If I move a VM from (standalone) host Host1 to another (Host2) by using replication, the rest of the cycle (Backup => Backup copy) always regards the VM from Host2 as a completely different VM. So Veeam would start transfering terrabytes of data to the offsite location even if the data is already there (!).

Have tried everything: replication maping + backup maping + seeding + permanent failover + removing VM from Host1 from backup job, adding VM from Host2 to the backup job...

Maybe vMotion would work but we don't have a license. So I am quite frustrated now as I've lost days trying to do something that's most likely not doable. We just want to move VM from Host1 to Host2, I never thought it would be impossible for Veeam to handle as the same VM (which it is). I still hope someone tells me there is a way to do it.

Bye

EDIT: just got an email from Veeam, saying there might be a way, I should have a look at:
http://helpcenter.veeam.com/backup/70/v ... liary.html
but I think I've already tried it

[foggy]

Well, each time you register VM within VI, it gets a unique ID, which is used by Veeam B&R to track VMs. So if the VM ID is changed (and replica VMs have IDs different from the original VMs), it technically makes them new VMs from perspective of our product. After re-adding VMs and mapping backup jobs, they have to read the entire VM image during the first job run. You can ask support for assistance in modifying product database to avoid this, though.

[marama]

Well, each time you register VM within VI, it gets a unique ID, which is used by Veeam B&R to track VMs. So if the VM ID is changed (and replica VMs have IDs different from the original VMs), it technically makes them new VMs from perspective of our product. After re-adding VMs and mapping backup jobs, they have to read the entire VM image during the first job run. You can ask support for assistance in modifying product database to avoid this, though.

Hi Foggy!
Yes, that sounds much better, I'll try to investigate in that direction.
Although I am really dissapointed - all I want do do is move a VM from one host to another. I understand it's different ID, but in my opinion Veeam should be able to handle it through basic functionality. Maybe in one of the future versions... if we were to buy Essentials+, would vMotion cover preserving of those VM IDs?
Although I really dislike paying >3.000 EUR just to migrate few VMs.

[foggy]

Yes, vMotion preserves VM ID and if vCenter is added to Veeam B&R console, VMs will still be backed up after being vMotioned, without any additional actions required.

[rdelc]

We moved our entire operation (24x7) business to a different location 10 miles away two years ago. We did not have single minute of downtime. We had over 164 virtual servers. We changed the infrastructure completely in the process going from Vmware 4 to version 5 on the target. All new host hardware, all new SAN hardware. We went from Dell R900 on Equallogic to HP DL380s on Hitachi.

The hardest part was the application planning. Our applications have to run. Some had short windows of outage, but we were able to coordinate them all. We also moved physical severs also in the process. But we are heavily virtiualized and Veeam performed like a champ.

One thing we had going for us was that we had 500mb pipe and we bridged the network. This basically simplified the the process of subnets and changing ips.

We had servers that had Terabytes of storage. One thing we did was once we had the initial replication done, we replicated often ahead of the schedule cut over. This made the last replication as fast as possible as we cut down on change blocks.

We are currently in the process of doing a similar thing building our DR site. This time we are going over routed network, with a lot less bandwidth. 60mb pipe works, but it is much slower because of the size of our VMs. One thing we are doing to alleviate and help with this, is we are seeding the jobs for the larger jobs.

thanks,

[albertwt]

RDelc,

Did you use the Storage Array replication technology or just using Veeam to replicate the VM at the hypervisor layer ?

[dellock6]

They moved from an EqualLogic to an HDS array, so I don't think there was any storage replication available between the two. Sounds like they used Veeam instead, based also on the seeding part ot the story (and the fact we are in the Veeam forums )