Using Veeam replication to Migrate Datacenter

[JosvwHLT]

Thanks Foggy, that's exactly what happened. We figured it out and fixed it with bringing additional DCs a live on the different locations so we could (and can) tackle the issue as you mentioned. Thanks for explaining !

[csinetops]

That's interesting with the DC issues, I bet foggy is correct. We migrated our 2 DC's across datacenters using planned /final failover one at a time without issues. I failed one over and let it sit for a few days ( longer than needed, probably only need a few hours), then failed the other over.

[csinetops]

whoops, sorry JosvwHLT, didn't see that you replied to foggy, glad you see the issue.

[scottmr]

Hosts are running Windows 2012R2 with HyperV role
Running Veeam B&R 9 with update 1

I need to move Exchange from Host A to Host B. Total size of Exchange is 780GB. I think the safest way is to shutdown, export Exchange then import to the new Host. That's likely to take a long time to accomplish.
I've been backing up Exchange and also have been doing a Replication Job on it.

I've moved other servers before using replication and doing a permanent failover, but never Exchange.

Any input is appreciated.

Thank you

[foggy]

Hi Scott, replication scenario with planned failover and subsequent permanent failover should do in this case as well.

[Heisenberg]

Hello,

I have a customer who wants to migrate 3000 VM's (190Tb in total) to a new greenfield data center.
Since we'll be using Veaam for backup we also want to use it or the migration.

Source environment is Vsphere 5.5u2 target will be 6.0u1.
Source and target have no shared storage and are several 100Km's apart.
There is a big dark fiber between the locations.

I've read the veeam manuals for quick migration but i can't find if veaam can move workloads to a different Vsphere version.

Any experience with this ?

Thanks !!

[chrisdearden]

That shouldn't be a problem, though you will probably want to schedule the appropriate vmtools and hardware version updates when it lands on the new platform.

[foggy]

I also suggest to review the thread above, since replication might be a better choice in your scenario (think planned failover).

[nunciate]

I replicate my entire VMware environment to DR each night. We recently decided to run all Development VMs in DR only and replicate them back to production just to have a fail-over plan.
All I did was power down the VMs in Prod, Performed a fail-over to DR with Veeam and then did a Make Permanent. Then I edited my replications jobs and reversed my replication to replicate from DR to Prod.
Ran the replication jobs and they synced up fine and all is running great.

[skneuper]

I am interested in the speed of a planned migration, stated in "virtual machines per minute". I've read the history of this topic and would like to go faster than 5-10 minutes per VM mentioned in one post.

Backstory: moving 350 or more virtual machines between two sites (80 TB storage used at each site) during a weekend, with all the machines replicated between the sites. Thus a "planned fail over" seems to be the method. If it makes it faster I might be able to arrange to have them all powered down for the event with minimal support at each site (NTP, AD, DNS) so that the planned migration does not have to deal with Microsoft AD, NTP, and DNS issues. I assume with proper construction of the replication jobs the planned fail over would have lots of parallel VMware operations and I would be limited by the IP bandwidth and such but obtain one per minute?@?!! And, I assume, planned fail over of a powered down machine results in a powered down machine at the destination end!?!?!?

--Steve (planning for data center move day)

[foggy]

Planned failover automatically shuts the original VM down prior replicating the latest changes and then starts the replica VM. So you do not need to power off them in advance, this will even increase the downtime. That said, I don't think one VM per minute is possible, since the overall process consists of powering the VM off, final replication cycle and powering replica VM on. But we are talking about several minutes of downtime only, from the moment the original VM becomes unavailable till the moment its replica is ready to serve requests, so if you were going to power all VMs down in advance, I assume you're ok with that long downtime? Also, to avoid resource constraints, it is recommended to perform migration in stages.

[JosvwHLT]

Today I replicated a live W2k12R2 DC to our DR site by means of a "planned failover". The process ended without any errors, the DCs seems to be syncing again with the DCs in our main site. Despite that I'm left with 2 questions:
1. The "panned failover" job ended 'ok', it reports the following : "Reverting VM to the restore point snapshot", "Powering on VM", "Failover completed successfully". What does the "Reverting VM to the restore point snapshot" message mean. Is the failed over server identical to the source server?
2. The "Directory Services" eventviewer reports eventid 1587 and 1999, indicating a change of USN. Is this expected behaviour after a "planned failover" of a W2k12R2 DC?

Additional information: After the "planned failover" I re-ip-ed the "failed over" DC because of having a different IP-subnet on the DR-site.

[Vitaliy S.]

1. Yes, it's identical. This restore point snapshot is created in case you want to trigger a failback operation and then continue using VM replica in the job. See this link for more info.
2. I believe it is expected, as 1999 event says the following:

The source directory service has optimized the update sequence number (USN) presented by the destination directory service. The source and destination directory services have a common replication partner. The destination directory service is up to date with the common replication partner, and the source directory service was installed using a backup of this partner.

[-=MACROS=-]

Yes, it is safe. When you plan to failover make sure you choose permanent failover option in the backup console to remove replica VM records from the console.

We had proceed exactly the same way (Microsoft Hyper-V). Works grate !!!

[millahjovich]

OK awesome, I didn't even know Quick Migration existed!

Thanks for the info guys, I will give it a go once I get the new kit and configure it!

[tedlw]

Hi,

I'm planning to renew my existing host that is running esxi 5.5.0 and I want to know what happends if i install esxi 6.5 in the new host
Can quick migration be done between diferent esxi versions?
Thanks

[DGrinev]

Hi Ted and welcome to the community!

That's shouldn't be a problem to migrate between different esxi versions.
However, i'd recommend to review this thread with different approaches.

Please be aware migration cannot be performed, if the target esxi version is later than the version on the source. Thanks!

[yallies]

hello,
is it possible to backup a vm from a Esxi vmware version and to restore it to another server with a different Esxi vmware version .
For example take a backup of a vm on Esxi V5.5 and restore it to a different server with Esxi V6 ?
regards

[nielsengelen]

This shouldn't be an issue.

[Vitaliy S.]

Niels is correct, for other considerations please review this topic.

[gravasio]

Hi,
we are actually running a VSphere VCenter 5.1 with ESXi 5.1 hosts and Veeam 9.5 for Backup.
Now we have deployed a new virtual infrastructure based on VSphere 6.5 (new hosts, new storage, new vcenter server) and I'm considering the options for moving the VMs.
First of all we cannot add the old ESXi to the new VCenter because 6.5 do not support 5.1 hosts and so I think we are left with two options:

### Option One ###
- mount the old storage NFS shares to the new VSphere
- shut down the vms
- import and power them on on the new VSphere
- use storage VMotion to relocate to the new storage

### Option two ###
- Setup veeam replication to the new VSphere
- Do a permanent failover of the VM

In your opinion what is the best way?
In particular I would like to keep veeam backups and offsite copy without the need to schedule new jobs and/or use additional backup space
I have a couple of VM that are about 5TB in size!

Thanks for the hints.
Giuseppe

[foggy]

Hi Giuseppe, option two with the planned failover is the way to go. Please see above for details.

[gravasio]

Thanks!
My main concern is keeping the backups and offsite copies from doing unwanted new full backups.
But in my test after I made a failover and commited it to the new vcenter, both the backup job and the replica job where still using the old VM on the old VCenter.

I'm doing something wrong?
Maybe I must use the quick migration?

Thanks
Giuseppe

[foggy]

VMs have changed their IDs upon being registered in the new vCenter, so it is expected that Veeam B&R treats them as new ones. Take a look at vCenter Migration Utility if you want to proceed with incrementals after migration.

[ecornwell]

Hello,

I've got a fairly complicated project ahead of me and was looking for some input to my thoughts. We have Hyper V based VM's spread across a few sites in our company. We want to centralize them in a primary datacenter but we can only afford a couple hours of downtime for the servers. They are physically located too far away to sneakernet the data to the DC. We also want to migrate away from Hyper V to VMWare. We were already looking at switching to Veeam for our backups so it makes sense to use all of the features we can.

My thought: Utilize the Veeam replication feature to replicate the VM's to the new DC. (I've never personally used it but read about it.) Once the data is fully replicated and we're within our maintenance window, do a permanent failover of the VMs to our DC. At that point, I'm free to do some sort of V2V to migrate the VM to VMWare. Once the site is complete, we can move on to the next. I feel like I'm over simplifying it a bit but it seems like the idea is fairly straightforward.

Thoughts?

Thanks!

[foggy]

Hi Eric, your understanding is correct, this is the way that is typically recommended in such scenarios. Please review the thread above for more details. Thanks.

[AdamC]

Has anyone done a datacenter move using B&R Replicas? The goal is to have zero RPO. We're using Vsphere 6.5 as our hypervisor. We already have seeded replicas at our DR location and would like to use those as our primary VMs at our move site. How can we leverage the seeded replicas to have zero RPO as if we did a geographical vmotion? Thanks

Adam

[DaveWatkins]

You can't have zero as far as I'm aware. At the very least you'll have to change IP's. You can get it pretty low but you'll still need to shut down then running OS and to a catchup sync, then bring the VM up in the new location. 15-30 min per VM is what we had when doing the same thing. I have failover plans in place that did the IP changes and most of the time was doing the final sync

[foggy]

Hi Adam, please review this topic for more information. Basically, minimum downtime with zero data loss is provided by the planned failover.

[myFist]

We want to migrate VMs from vSphere 5.5 to vSphere 6.7 withouth storage vMotion. Is the replication the right way for the least downtime?