Moving VMs to a new virtual center.

[veremin]

I believe the support team has a PS script that changes vCenter reference inside the product database. So, it might be worth contacting them. Thanks.

[gccit]

It really would be great if there was a way to map VMs between an old and new vCenter. (I think) I understand why it's so problematic for Veeam - registering VMs to a new vCenter generates new vmid/moref's and probably breaks CBT as well. At least in my case - I don't really care about a temporary spike in space needed to store backups - take a new full and keep on going - no problem. I'd just like to be able to run a script and match up VMs (by name?) so that the existing jobs and retention periods stay intact and Veeam can appropriate manage the aging out of those backups.

In my specific case today, I'm looking to move from Windows-based vCenter install to the appliance version, so migrating the database just isn't an option.

Surely there's a way...

[cgreentx]

We are in the same boat at multiple clients. After version upgrades through many versions of vSphere, 5.5 brings the desire to move to the virtual appliance. Moving to a fresh database breaks our Veeam Backup and requires us to start completely from scratch. It seems that even having a simple re-map tool to match up the backups to VM's in the fresh vCenter should be completely feasible, even if it required a full re-scan to compare.

[foggy]

Guys, have you contacted support to request the script mentioned by Vladimir above? Not 100% sure it is applicable to the described scenario, but worth a try.

Anyway, thank you thank you for the feedback.

[Vitaliy S.]

Hi Chris,

Just out of curiosity - why did you migrate your installation to vCenter Server appliance? For me it creates additional issues with backup and brings no visibility in what is going on inside the appliance, I'm not a Linux guy at all..

Thanks!

[gccit]

The script mentioned wouldn't help. Anytime a host is registered to a new vCenter, all associated VMs get new IDs in inventory. These are the references Veeam uses to identify the VM in a job.

As far as why the appliance... That's really outside the scope of the topic here. This ID/inventory issue is a problem for anyone moving to a new vCenter - regardless of platform - and there are plenty of documented cases for why one might need/want to do this on occasion.

Just for fun though, I'll play along... The upgrade process for vCenter continues to get more and more convoluted. The appliance makes it easy. For the SMB segment, when we're only managing a handful of hosts and < 100 VMs, the appliance just makes sense. I don't need any "visibility" - I just need it to work.

[veremin]

The script mentioned wouldn't help. Anytime a host is registered to a new vCenter, all associated VMs get new IDs in inventory. These are the references Veeam uses to identify the VM in a job.

As far as I'm aware, this is the exact use case the mentioned script has been designed for. So, it's certainly worth contacting support team. Thanks.

[gccit]

OK - I've opened a ticket to investigate this. Tier 1 claims to know nothing about said script, so they are passing to Tier 2. Hopefully I'll find someone soon who knows how to get it to me.

[veremin]

Can you provide the ticket number, so that, I can track the case and hopefully have the right person chime in? Thanks.

[spgsit5upport]

Upgraded my VC 5 to 5.5, but on a different server (copied DB)

So technically it is VC upgrade. hence I expected all VMs IDs to be the same

But VC object in Veeam changed (different name/different IP) - I could not use alias route - http://vninja.net/virtualization/preser ... g-vcenter/, as the original VC server is still being used for different live purposes)

So I edited the jobs, removing VMs & adding the same VMs from new vCenter

But strangely each job now runs as "new" taking no notice of what is already in repository

Which mostly does not matter, apart from one job that is 5 Tb & takes ~ 30 hours to couplet first time round

Anybody any suggestions?

Seb

[foggy]

So I edited the jobs, removing VMs & adding the same VMs from new vCenter

But strangely each job now runs as "new" taking no notice of what is already in repository

Seb, have you mapped the jobs to existing backup files after re-adding VMs?

[VER]

Same problem over here, Tier 1 knows nothing about a script and says that it isn't possible. My case id is #00563517

[veremin]

According to the case, your problem seems to be slightly different to the one discussed above. You don't want to move VMs to a new VC, but rather to change VC FQDN. Support team has PS solutions for both problems.

Anyway, I've asked the support engineer who is aware of the said solutions to take over your case.

Hope this helps.
Thanks.

[VER]

According to the case, your problem seems to be slightly different to the one discussed above. You don't want to move VMs to a new VC, but rather to change VC FQDN. Support team has PS solutions for both problems.

Anyway, I've asked the support engineer who is aware of the said solutions to take over your case.

Hope this helps.
Thanks.

Thanks!

[veremin]

You're welcome. Let me know if additional assistance is needed. Thanks.

[spgsit5upport]

Seb, have you mapped the jobs to existing backup files after re-adding VMs?

Yes, I have had done it.

Anything can be done to database itself, so I do NOT get the same 5 Tb backup job happen again? I have no space for another copy on that repo

Seb

[foggy]

You could replace the moref ID in Veeam B&R database with the new one, however this is not generally recommended and can lead to undesired consequences.

Btw, what backup mode do you use? Please note, that in case of reverse incremental, similar blocks will be deduped, so you would not need another 5TB of space.

[spgsit5upport]

I use reverse incremental

I tested on other jobs (I have few). Each one just copied majority of the total amount (while might not be full amount, it was still pretty lot)

I am willing to change the moref ID & take the flack for it (where to change it?)

Seb

edit:

Used this:
http://www.interworks.com/blogs/ijahans ... ror-vmware

but the VM id did NOT change in the job.
So no idea why Veeam make the "new" backup in SAME location

[foggy]

Please contact technical support directly for assistance. If you post case ID here, I could probably ask the right person to take it over.

[spgsit5upport]

Too late, backup is on 27% currently , in another 18 hours it will finish, in the meantime, as I have not enough space, I will have to delete previous one from repository.

But not an expected behaviour. I even restored VB&R previous DB to compare jobs & they are exactly the same! (apart from VC DNS entry of course)

[gccit]

So I asked about the script as instructed on Monday. It's Friday and I still have nothing. What can I do? Case 00561509

[foggy]

But not an expected behaviour. I even restored VB&R previous DB to compare jobs & they are exactly the same! (apart from VC DNS entry of course)

Do you mean VM has the same moref ID but still full backup is triggered for it?

So I asked about the script as instructed on Monday. It's Friday and I still have nothing. What can I do? Case 00561509

I will check the case.

[veremin]

Small addition - if you've moved VMs to new vCenter, and have already run jobs, there is nothing we can do in this case. The mentioned script should help when nothing has happened since VMs were registered under new VC. Thanks.

[v.tom]

I'm wondering if Veeam could provide a procedure for migrating from one vCenter to another?

We have a lot of customers who are moving away from the Windows based vCenter Server to the Linux based vCenter Server.

A lot of configuration is lost like disk excludes, which is a lot of work to do again.

[veremin]

Situations when you're planning to register VM under new vCenter server and meanwhile preserve existing backup jobs' configuration are addressed on case by case basis. You can open a ticket with our support team and post its number here, so that, I can ask the right engineer to take over your case. The only requirement we have is that after migration you shouldn't run backup jobs, but rather postpone them, till the database correction is performed.

Thanks.

[mrstorey]

Hi,

I understand that Veeam tracks VMs using their unique identifier in vcenter, but I wondered if there was a way to map previously backed up VMs to their new IDs in the event of a host being removed and re-added?

We had a situation last night where a host wasn’t joining back into venter after a datacenter power down - it looked like the vpxa agent was crashing - the host momentarily reconnected after selecting ‘connect’ but immediately disconnected again.

In hindsight I should have just manually reinstalled the vpxa agent, but it was late, wasn’t thinking at my best and I just removed and re-added the host to get vcenter to reinstall it for me. This got us back with a full functioning cluster and I went to bed.

The backups are due to kick off again later this afternoon, and I know Veeam will create duplicate, active full backups for those VMs registered on the host I re-added.

We don’t have a great deal of backup repository space, so I wondered if there was a way I can map these new ID’s to the existing VMs in the backup job? It’s probably worth noting that we target VM folders for our backup jobs, so new VMs are picked up automatically.

Any ideas?

Thanks,
Alex

[veremin]

Hi, Alex, you can disable existing jobs temporarily and ask support team for assistance. Chances are, they have a solution for this issue. Thanks.

[cody.ault]

At the moment the officially supported way of fixing this is to add the new vCenter into Veeam, clone the old job and remove and readd the VMs into the job under the new vCenter. Removing and readding the VM's to the old job will potentially cause issues when restoring with names/ref-id matching and can cause some confusion in the restore wizard. After the new job is created you will need to run a new full backup and start a new chain. For Replicas, you can readd the VM's to the job and use the Replica Mapping feature to point to the existing Replica VM's. This will cause it to delete the existing snapshots (restore points on the replica VM's) and start collect the disk digests which can take some time to complete.

[Gostev]

We are working on the support tool to facilitate vCenter migration scenario, this should become available in the same time frame with v8. Thanks!

[dellock6]

Oh, this is a great news! Surely will be an appreciated tool