VM moved to new vCenter

[foggy]

Yes, for those jobs that haven't run after that yet. For those that already triggered, please wait for them to complete. I'd recommend to ask for support assistance with the migration tool.

[joebranca]

We are planning to ferry groups of VMs over from our 5.5 environments to a new 6.5 environment over the course of the next month or so. Without understanding what's involved with either option:

Does the migration tool only make sense to apply if all VMs are being migrated in one shot, or does it help throughout the staggered migration process?

Would it be better to get assistance with how to do manual changes in the db for each batch of VMs that get migrated?

Or just bite the bullet and re-add the migrated VMs for new full backups, and document for self service end users the roundabout methods that must be done for restores from the older 6 weeks of restore points when they are needed?

[foggy]

Hi Joe, you can plan to migrate in stages and use the tool at each stage for the corresponding VMs. I recommend to at least get assistance for the first time to get acquainted with the process so that you could use it yourself further.

[joebranca]

Thanks foggy. I have opened a case with support to walk through for migrating one of the proxy VMs which I have put in a Veeam backup job to test this out.

The documentation tripped me up when it says in the Considerations and Limitations section "Old vCenter should not be used by Veeam Backup & Replication any more after migration." This sounds like a global limitation once the utilty is used for any VM migrations, even though we would need to continue backing up VMs in the old vcenter that have yet to be migrated. Does that actually mean old vcenter should not be used for any VM objects in a particular back job once migrated VMs have been re-added to that job? I'll also ask support for clarification.

joe

[foggy]

Yep, better ask your support engineer, since I'm not well-informed about this utility specifics.

[joebranca]

A test migration and run of the script was successful; however a question came to my mind after the support case was closed.

The support person mentioned that multiple runs of the script may lower success rate for migrated VMs. For migrated VMs that don't work properly with the script, obviously self service FLR operations will not work for the older pre-migration backups. What would be the best approach, if any, for getting files restored from pre-migration backups on to the migrated VMs? Will users with appropriately configured roles be able to "Download" files locally from the pre-migrated backup chains? I'm wondering how to forewarn users what needs to be done for FLR from pre-migration restore points if the script didn't work for their VM.

[foggy]

I believe only restore to original location will not work for such backups.

[MJeB]

Hello,

first off our environment:
Two ESXi Host in different locations managed by a vcenter.
One veeam proxy per host, one dedicated veeam master server with veeam b&r 9.5.
Existing veeam jobs (8 reverse incremantal jobs with a number of VM) and corresponding copyjobs.

Problem:
We have to move the VMs to 2 new hosts that are managed by 1 new vcenter.
The old vcenter DB can't be reused/migrated to new vcenter.
The VMs and datastores will be disconnected from old vcenter and reconnected to new vcenter.

We have added the new vcenter to the existing veeam b&r infrastructure in the hopes this would be enough.
The moving of the VMs/datastore to the new vcenter onfortunately changes the MORef of every VM/datastore resulting in veeam not knowing the VMs anymore.
The only solution we found so far is https://www.veeam.com/kb1299 which causes the VMs to be treated as new VMs causinging new full restorepoints to be created.

Question:
Is there any way to migrate the old backups in a way that veeam can use these without being forced to create new full restorepoints?

Thanks and best regards

[ejenner]

Maybe backup mapping? Not sure: https://helpcenter.veeam.com/docs/backu ... l?ver=95u4

[DGrinev]

Hello,

Unfortunately, you cannot continue the existing backup chains by mapping new backup jobs with the "new VMs" (due to changed moRefIDs). Thanks!

[MJeB]

Thank you Dgrinev,

I was afraid it would break down to this, but hope dies hard, so was worth a try to ask.

[ejenner]

Don't give up yet!

This might work: https://www.veeam.com/kb2136

[brichardson1991_obk]

Hi Guys,

What is the best way for my scenario below:

I have 3 hosts running ESXI 5.5 in a vCentre and we need to move the VM's up to a supported version of ESXI
I have 2 hosts running ESXI 6.7 with vCentre.
I was planning on doing a Replica job to move the required VM's from the 5.5 host to the 6.5
My only concern is keeping the VM's backed up as they are now without running a full job but on the new vCentre.


Am I right in thinking if we replicate them over they will have new ID's but this can be synced up on the backup server's sql database via support?

[stryker54141]

Hi all,

I think I made a mistake this past weekend and I'm hoping someone can help. I upgraded (using the migration method) my vCenter server from 6.5 to 6.7 and deployed two new ESXi hosts. I migrated my VMs to the new hosts and decommissioned the old ones.

When I ran my backup job yesterday, I received the message that my VMs were no longer processed by this job. Upon investigation, I found that my jobs were configured through the "Hosts and Clusters" instead of "VMs and Templates." (not sure if this is the problem)

If I add my VMs to the job, Veeam sees them as different machines. Is there anyway that I can continue using my existing backups? I have these jobs tied to a backup copy job along with a remote backup. I hate to start my GFS over.

Thanks for any help.

David

[wishr]

Hi Ddejarnett,

That's an expected behavior as Foggy mentioned above in this thread. Please take a quick look at the thread contents and let us know if you have any additional questions.

Thanks

[stryker54141]

Wishr,

Thanks for replying, but I don't think my scenario matches this thread. I did not create a new vCenter, I performed an inplace upgrade/migration from 6.5 to 6.7. From my reading, this will maintain the VM IDs. Am I wrong?

David

[DGrinev]

Hi David,

You're right, all VMs morefIDs should have been preserved during the VMware native migration.
Can you clarify how exactly your hosts added in the Veeam B&R, separately or as a part of vCenter server? Thanks!

[stryker54141]

DGrinev,

Under the Backup Infrastructure section, I added my vCenter Server and then when I configured my jobs, I used the "Hosts and Clusters" tab and selected my machines.

David

[DGrinev]

It doesn't really matter which vCenter tree was used to pick the VMs, since you are working with the vCenter server.
This is unexpected behavior and deeper investigation is needed, please contact the support team and let them take a closer look.
I am not sure the issue comes from the Veeam side, but anyway our engineers will help you reveal the root cause.

Thanks!

[stryker54141]

Thank you. I just opened a case.

[PKaufmann]

I am planning this migration right now (from 6.0 to 6.7).
Was your case resolved? any useful information?
thanks.

[stryker54141]

PKaufmann,

Performing a migration (per VMware instructions) did not work properly and caused the VM refIDs to change so I had to use the vCenter Migration Utility (https://www.veeam.com/kb2136) to adjust the refIDs. After doing this, my jobs ran fine. Only downside to doing this was that I had to perform active full jobs to my cloud backup.

Hope this helps.

David

[PKaufmann]

Hi David,
thanks for your reply.
I will have the utility at hand when I am doing the migration..

[gibit]

Dear all,
i need your help to make sure what i'm planning will be ok..

Today i'm on a vsphere cluster made of two 5.5 nodes, where i'm running 30 vms , and a B&R 9u4 server .
I need to replace this old cluster with new storage and new servers, running vsphere 6.7
Backup repos will remain the same CIFS repos i'm using today
I can afford some downtime, and also a pause in backups, during the weekend

What i'm thinking to do is
- Pause backup for each VM, and copy it to the new cluster using B&R Replication (any better option to suggest?)
- Stop replicas and start VMs on the new cluster
- Stop Veeam services, backup configuration, and shutdown the server
- Install a new Veeam server on the new vsphere cluster, and import configuration (better start with same version 9u4, or it could be safe installing directly v10?)
- Activate Veeam license on this new server

At this point, i will have all my backup jobs configured but i guess none of them will be working because of the changed VMs ID.
How can i manage this? Editing each job selecting the corresponding replicated copy of the vm the job will start a new full backup? And in case i will need to restore any older backup , will it be possible ?

Anything else to keep in mind?
Any suggestion will be appreciated

[HannesK]

Hello,
and welcome to the forums.

What you plan looks good, but I don't understand why you want to set up a new Veeam server if you only migrate your VMware. If necessary, then I would start with U4.

Correct, the jobs will not work because of new VM IDs (morefID).

I recommend to start with a new full backup. I also think it's a little bit "too complex" for your scenario to work with unsupported database edits

Best regards,
Hannes

[gibit]

Ok thank you Hannes
So you mean i can just replicate Veeam server as any other vm and start it on the new infrastructure, ok. This way i will also not need to reactivate the license i guess

As per morefIDs , and new full backups, it's ok running full backups, but what i'd like to avoid is creating new jobs.
I mean i'd want to match the new id with the existing job, without duplicating them. Is it possibile ?
Also, what about copy jobs? will they be impacted by these changes?

[HannesK]

yes, it's not "great" to replicate the VBR server, but for one-time migration I don't see a big issue (SQL freezing is an issue, but well, if it fails once, just try it again)

You need to re-add add VMs to the jobs. For the jobs, all VMs are new.

[hgreguric]

Hello,

My question is, I am not sure if I understood what the vCenter migration tool does correctly, we want to failover VMs to the DR site, once VMs are failovered/restored they will get new morefID, now my question is, we will do the failover and is it then possible to use the vCenter migration tool to just re-map the morefIDs without doing migration of any VMs?

We don't want to migrate anything with the tool, we are just looking is it possible to re-map the morefIDs with the utility so we don't have to do it manually on the Veeam DB.

[Vitaliy S.]

Hello,

Changing exiting moref IDs for replicated VMs is not possible via this tool. Once you started replicating VMs, they are already treated as new by the vCenter Server. Can you please clarify why do you want to change more IDs for replicated VMs? What's the end goal?

Thank you!

[hgreguric]

Hello,

Once VMs are replicated/restored to the DR site they will get a new MorefID and our backup chain will stop so I am looking what are out options in this case. One of the options I googled is to alter Veeam's SQL database but I am thinking is there a more elegant solution that doesn't involve tempering manually with SQL?