Moving VMs to a new virtual center.

[wojciech.bajorek]

This is unfortunately not going to help me as the new job and new replicas will still require >50TB storage.
Still, it's a nonsense.

[davide.depaoli]

Hello,
my customer has just replaced all vSphere infrastructure with new servers and new vcenter (from 5.5 to 6.0 with new hostnames and ip addresses).
All (a lot of) Veeam jobs are pointing to old vCenter/ESXi hosts that are turned off.
Is there any (fast) way to reconfigure jobs in order to point them to new hosts ?

thanks in advance
Davide

[Shestakov]

Hello Davide,
Did the customer replace production hosts or targets of replication jobs?
Thanks!

[davide.depaoli]

Hello,
have replaced production hosts. He doesn't has replication jobs, but only backup.
The storage and repositories has not changed.
I have found an old post (https://goo.gl/Zzb6aQ) talking about a migration tool. Is it suitable for this case ?
tnx

[davide.depaoli]

Another important question: have read that with new vcenter, Veeam starts a new backup chains with a first Full backup (because from its point of view, all VMs are new objects). Is it true ?
In this way, I have my repositories filled with old backup files, that are no longer used by the new jobs. True ? If yes, is not possible to remap new jobs to existing backup files ? Or I have to delete old backup files to have enough space to accomodate new chains ?

tnx

[Shestakov]

Since you have new vCenter server, all VMs have new MoRef IDs.
Indeed the tool can be used to match the VMs with older jobs. You can find the utility here.
Otherwise the backups cannot be matched with VMs.
Thanks!

[micoolpaul]

Morning,

Feeling the need to vent here about something that I consider shockingly basic.

I upgraded from vCenter 6 to 6.5. Had to reconnect my hosts after the upgrade. Didn't think anything of it, then the nightly backup failed. Not the biggest deal I thought, I'll be able to remap them or something, no you can't remap them in a backup. Telling it to recalculate is now telling me 0 bytes to backup. Remove and re-add the VMs to the backup job and use the map backup button. Check when the nightly job is running and it's processing all the data again, initially I'm thinking this is okay maybe it's a CBT reset due to all this, then I look into my backups and I can see it's making duplicate entries of all my VMs! So 6TB extra disk space wasted later on another full backup and it comes to the turn of my backup copy job. No surprises that it decides to copy all 6TB of backup over my 100Mb link again. So nearly 14 hours later and it's on 1%. At this point I feel the need to add the moment I had the problem with object not found I started searching Veeam's knowledge base but it was only giving me messages to do with Veeam 6.x and 7.x nothing to do with the migration tool.

I called up Veeam technical support and they've said that because the VM references are different this happens. I can't get my head around how you can do replica mapping where VMs can be on complete different data centers with different references and yet still map however you can't do an incremental backup after mapping an existing backup and then have to clone all the VMs again.

Then after speaking to Veeam technical support they've told me to use the Veeam Migration tool which is the first I've seen of it and was told to just cancel my backup copy job etc. But then reading the KB article because the backup ran I now can't.

So I'm stuck wasting an additional 12TB of backup storage between my DC's to preserve my backup chains, either got to start doing a backup to disk and then try to seed it to the other site or wait for it to run which'll likely take another week and got Veeam technical support telling me to run a tool even after I've told them that a backup has already run. All because a feature such as map backup doesn't do anything you'd expect it to and they've got a vCenter migration tool sat as a separate tool in a KB rather than integrated into Veeam itself to deliver a supported reconnect scenario.

Really disappointed in this. Been using Veeam for years now and never had it blow up on me as dramatically as this before. Done vSphere 5 to 5.5, 5.5 to 6 and expanded to multiple vCenter with no issues, worked all the way from Veeam 6 to 9.5 then another trivial vCenter upgrade and suddenly my backup window is destroyed and the Veeam support team are just telling me I'm out of luck or telling me to use unsupported tools in conditions their KB is strongly advising against.

Case # 02195767 if anyone from Veeam wants to look into it though I imagine it's all too far gone to save this time.

[micoolpaul]

So I'm going to ignore the fact it's been nearly two days and nobody from Veeam has acknowledged this and I'm going to try and put this into a positive context.

Dear Veeam,

I feel like your map backup option is currently lacking a very desirable feature. You have a button to map a backup but it gives no form of feedback. It would be a great improvement if after pressing this that we were told what backups have been mapped and which ones haven't been mapped from the job in question. It would allow us to proactively work out if we are going to have problems with our backups ahead of our next backup schedule. Maybe not even when you press map backup but maybe when finishing and saving the config changes to a job and map backup has been detected it can prompt to do a lookup of the VMs in the job against existing maps to provide a list/report, that'd be handy too!

Thanks,
A long term customer

[Pat490]

did you migrate to 6.5 or reinstall fresh VC? if you did not migrate, than all VMs have new MoRef ID's.
Did support advice you to use the Migration Utility? https://www.veeam.com/kb2136

[micoolpaul]

Migration. But they've got the new references as I had to reconnect my hosts (I know that's not normal behaviour)

Backups then failed, i tried to self help with the KB but searching for the error string gave me nothing remotely relevant to the migration tool, neither did google. So I tried map backup which did nothing. Then after removing and re-adding them to the job it created the new ones. Then support poorly advised to run that tool after my new backups had run.

It's over now, I'm stuck with a week of no backup copies whilst the initial ones copy again, losing 12TB of storage for a while until retention window is met again. And a wall of silence still from Veeam. Such a happy customer right now. It just works.

[Vitaliy S.]

Michael, please review this thread for more reading on the behavior you see. In case of moref ID change the migration utility is the only tool that can match the moref IDs of the VMs. Backup mapping cannot change the moref ID of your source VM (since it is a production infrastructure) and cannot touch/modify already created backups.

[micoolpaul]

Hi,

I understand why the error has happened now etc that bit I get, I also understand I've no other choice but to let the initial backups complete so I can then move on from this, what I'm requesting is that this functionality gets built into Veeam so nobody else has to go through what I'm going through.

Thanks,
Michael

[kroerig]

Hello!

I had to recreate our vCenter server on a new maschine. I added it to Veeam but I cannot delete the old one because backup jobs are using it.

How can I easily link the new vCenter server to the backup jobs without having to recreate them.

Thy,

Klaus

[mma]

Hallo Klaus

You have to change your job selections (folders, tags, vms...) to the new vCenter.
That's the easy part. "Bad" thing ist the new MorefID every VM gets...

vmware-vsphere-f24/moving-vms-to-a-new- ... 0-150.html

Check this with support before you run a job with the new selection!

Regards
Marcel

[veremin]

In order to avoid new full backups, check the vCenter Migration Utility discussed in this thread. Thanks.

[5mall5nail5]

Hi all - I had to remove an ESXi host and (the VMs on its local datastore). When I add them back in and kick off Veeam, it doesn't reference the existing backups/incrementals. Problem is, one of my VMs is 12.9TB and I really don't want to have to run for 2 days doing an initial backup again. I do have the original VMs backup content on disk in the Veeam server. And, the VM was added back in and is the same VM that was removed. Is there a way to tell Veeam "don't create a new backup, use what's there"?

[Rishi]

Yes, You can map existing backup data to new jobs. Just follow these steps: Create a new job/ edit a existing job -> in storage tab-right under Backup repository Click on "Map Backup" and select the backup file already in storage and you are done. Data gets mapped to this new job. Also documentation link for reference : https://helpcenter.veeam.com/docs/backu ... tml?ver=95

[5mall5nail5]

I should add - I had to add the VMs back into inventory, so the IDs must have changed.

[foggy]

Mapping the job to existing backup will not help, VMs that have changed their IDs will be still considered as new ones. You need to match the old IDs with the new ones, however, I'm not sure the vCenter Migration Tool mentioned above covers the standalone ESXi scenario.

[Rishi]

Mapping will work. The first run will read the entire VMDK, but any blocks that are already in the backup will not actually be copied.

[foggy]

This is valid for reverse incremental backup mode only (and with per-VM chain setting disabled). In case of forward incremental, all the blocks will be copied to a new VIB file that will be similar to the full one in size.

[CraigV]

Hi All,

We have to move and split an existing ESXi cluster. Currently it is a 7-host cluster, which will be split into a 5-host non-production cluster and a 2-host production cluster.
Currently all backups are provided through the use of a single Veeam server pointing to this 7-host cluster.

I'd like to know the following (assumptions of mine are in brackets):

1. What are the implications for Veeam when migrating the VMs to the new clusters? (I'd assume that we would just point Veeam to the new VC which in turn would allow it to see the new split clusters);
2. When we split manufacturing servers onto the production cluster, we would have to redo the backup jobs and settings. Veeam would not reference the old backups anymore, correct? We would then let the backups run for the set retention period, after which Veeam would expire the older backup sets of these VMs;
3. For the VMs that are left on the non-production cluster, would we be able to modify the backup jobs to include the remaining VMs on the 5-host cluster and then continue backups to the same directory etc. as per normal?

If I haven't explained it better, please let me know. Ideally we are trying to make this as pain-free as possible.

Thanks,

Craig

[foggy]

Hi Craig, generally, your understanding is correct. The main implication here is that uUpon being registered in the new vCenter, VMs will get their new IDs and be treated by Veeam B&R as new ones. This would mean the necessity to re-create the jobs (or re-point them to the new vCenter) and result in full backups of such VMs. Old backups will need to be managed manually, unless you continue running old jobs that will finally apply deleted VMs retention to them.

[CraigV]

Mmm...thanks Foggy. I was hoping that with a dedicated VC and separate Veeam server, it would simply continue with the jobs as per normal. I will make a note of this as part of the project.

Thanks for the help!

[marius roma]

Imagine a VM whose name is VM1 managed by a vCenter Server named vCenterOld.
VM1 id backed up in Job1 managed by a Veeam B&R server.
Job1 performs incremental backup.
Due to HW issues vCenterOld was replaced by vCenterNew and all ESXi hosts were detached from vCenterOld and connected to vCenterNew.
I reconfigured the Veeam server to connect to vCenterNew but I had to manually edit each backup job by removing all VMs managed by vCenterOld and add the same VMs managed by vCenterNew.
The result was that a new full backup is created for each job.
How can I tell the Veeam server that in Job1 the current VM1 (managed by vCenterNew) is the same as VM1 (managed by vCenterOld) and that the new backup of VM1 (managed by vCenterNew) must be chained to the old backup of VM1 (managed by vCenterOld) without creating a new full backup?
Regards
marius

[Andreas Neufert]

Hi Marius,

This is described at https://www.veeam.com/kb2136

[davidpfeiffer]

Hi,
Case # 02622019
Had to build a new appliance as the VMware Migration utility kept failing when trying to migrate from Windows vcenter 5.5 to new 6.5 appliance.
VMware could not figure it out.
Migrated the ESXi hosts to the new vcenter appliance today Version 6.5.0 Build 7515524 and went to run the veeam.backup.vmmigrator.exe tool.
When running the perparemigrationtask putting in the old and the new vcenter names I am only getting the old VM-IDs from the old 5.5 appliance.
No new VM-IDs are showing up.
Any ideas?
Thanks,
David P.

[Vitaliy S.]

David, since this is a support tool, then your engineer should be able to assist you with this. Keep working with our engineer and let us know what would be the solution.

[davidpfeiffer]

Thanks.
Appreciate the response.
This is all I got from support:

If you are unable to get the utility to run successfully or detect the reference IDs of the migrated VMs you always have the option starting a new backup set or manually updating the VMs reference IDs by following the steps in the KB below.

https://www.veeam.com/kb1299

Any other ideas?

[foggy]

Hi David, if you're unable to use the tool, then I don't think you have any other options than those mentioned by the engineer. You can try to escalate the case to get help with the tool itself, however, keep in mind that it is not officially supported, so I cannot guarantee that they agree to help with it.