Moving VMs to a new virtual center.

[readie]

Sorry Foggy, that was a different (but similar) problem back in Feb this year. And I didn't get any sort of script from support or anything to do ID matching (is this possible?). They just suggested removing old replicas and mapping to the new VMs with new IDs.
I am now ready to move to a new VCenter V6, and really am asking whether the help from support WILL enable me to do ID matching so that no full backups are started (in most cases I don't have the storage space, even with scale-out repositories, to keep restore points AND start new full backups).

[foggy]

You'd better ask support about this, since the tool they use for ID matching is not applicable to every scenario, as far as I know.

[readie]

OK will do thanks.

[readie]

Support provided a Migration Tool which was simple to use. The main time consuming bit was me manually going through the text file produced, to determine why there were duplicates (usually because we had, in the past, deleted a VM and recreated a new VM with the same name) and other bits and pieces that the migration tool was not happy about. Running the migration tool was otherwise straightforward (once I had found the English instructions to replace the Russian ones which come with the tool! ). Backup jobs were simple to tweak and got them running easily. Replication jobs took a little more manual work remapping each VM, but these too are now working fine (apart from the very time consuming 'Calculating Digest for HD . . '. Strangely one VM has a 150GB HD which has taken about an hour, and another has a 100GB HD which took 4 minutes? The latter had failed back to network mode, rather than HotAdd. Should I investigate this further? I don't need to as I'm not planning to move to another VCenter server for some time!!)
Good service from Support. (Case 01767739)

[veremin]

Strangely one VM has a 150GB HD which has taken about an hour, and another has a 100GB HD which took 4 minutes?

You can compare statistics for the both VMs, whether read, processed, transferred metrics are more or less the same or different.

The latter had failed back to network mode, rather than HotAdd. Should I investigate this further?

You can check the recoverability of these VMs just to be sure.

Thanks.

[dlieshout@client.nl]

So where can we download that Tool?

[nielsengelen]

As mentioned in this thread you can get this via support as they will assist you with it since it isn't just a free tool you can use at every case.

[Peejay62]

Hi,

I migrated from VC5 to VC6 this weekend. thanks to the tool Veeam supplied for re-mapping the vm id's everything went fine. I found out that it is important to re-map all your jobs if they are container-based. Somehow the container is still referring to the old VC. So, edit job, delete container, re-add container. If you have a copyjob for that backupjob re-define in that copy again the source for the copy (in my case the backupjob) and re-map the copy again in the repository to the copyfile. Do this after the (new) backup has run.
All my jobs where running incremental again as where the copy's. I did some test-restores on various vm's (files and instant) from various restorepoints to see everything is ok, and it is.

Grtz, Peter

[foggy]

I found out that it is important to re-map all your jobs if they are container-based. Somehow the container is still referring to the old VC.

Most likely container ID's have also changed during the migration process - expected in case of a completely new vSphere installation, not an upgrade of the existing one.

[BlueComp]

Issue: when removing and re-adding VMs or hosts to vCenter all backup jobs referencing these VMs need the VMs re-adding. I'm aware that this is because vCenter creates a new VM-ID for the VMs and there is 'a reason' why Veam can't track the VMs by name or similar.

Will things always be like this? just had to remove and re-add a host and then realised with a big sigh that I now need to go and fix all my backup jobs...

[foggy]

Support is able to provide assistance in addressing this issue.

[BlueComp]

Thanks Foggy, but that doesn't answer my question. I can recreate the jobs / remove and re-add the relevant VMs, but I'd like to know if I will always have to do this in future versions?
Or will the tool be built-in in future? Or is it always a case of opening a support case or manually re-mapping? Opening a support case is not ideal as the backups / replications fail until the case is resolved / tool provided. Which means we have to open a top priority ticket...

[veremin]

For now the tool is used only within existing support ticket. And currently there are no plans to change it in the nearest future.

However, how often do VMs in your infrastructure get new MorefIDs assigned?

Thanks.

[BlueComp]

Well I don't get to choose when my VMs get new MoRefIDs, in this case there was an issue with one of the hosts (the operation is not allowed in the current connection state of the host) and while troubleshooting this I removed the host and re-added it, then remembered that I had just broken all my Veeam jobs (my fault).

I understand there are technical limitations and that you don't want to issue a tool that could break things for some people. I think my best course of action might be to remove and re-add a host, raise support, get this tool, test it and then I can hang onto the tool for future use?

[foggy]

Yes, you could use the tool in any future similar case then, however, I'd consult with support in case of a different scenario that resulted in moref ID changes, since, as far as I know, the tool might not be applicable in some cases.

[tommls]

Would someone please refer me to what I'm supposed to do wrt Veeam and a new vCenter VCSA??

We're on vSphere 5.0 now and the vCenter server is a vCenter 5.0 Windows server.
We're moving to vSphere 6.0 U2 and a 'Linux' VCSA vCenter appliance.
I can if necessary re-use the same IP address for the new vCenter but not the server name.

Or should I use a new IP address as well as a new server name for the VCSA?? -- which would perhaps be much easier...
From what little i have read so far methinks I should leave old vCenter running as long as possible while new vCenter takes on the 6.0 hosts so I can more gradually move Veeam stuff...we have Exagrid backup devices at this site.
But I was planning to temporarily have the VCSA manage both the 5.0 and 6.0 host clusters (3 hosts each) for awhile while the 2-month trial license is in effect.

What is the EASIEST way to deal with Veeam's issues wrt changing vCenter servers??
Should I upgrade to v9 first?? -- does that make things easier??

I asked support but they will take a loooooonng time to reply...

I found this on a website, will this work??

"Thankfully there is an easy way to work around this issue, without having to mess about with the Veeam B&R database: Create a DNS alias!

That's right, the solution was that simple. I created a DNS CNAME alias pointing the old vCenter network name to the new vCenter network name. After doing that, I had to re-enter the credentials for the vCenter connection in Veeam B&R to force a reconnect, and all of a sudden all existing backups jobs where present again and working as intended.

The reason this works, is that when you change the vCenter name and/or IP address (or even move it to a new server) it does not change the VM identification number (vmid) or Managed Object Reference (MoRef), in essence the VMs stay the same and Veeam B&R can continue managing them as before."

Thank you, Tom

[Dima P.]

Hi Tom,

Kindly, review this thread. You may need to request a migration tool from support side, so if I were you I'd continue to work with the support team to avoid any possible ‘collateral damage’

[flaren]

Dear Veeam Customers,

If you come across this thread, please visit https://www.veeam.com/kb2136 about Migration Tool support status

[wojciech.bajorek]

Hi,

I'm wondering - did anyone manage to switch ESXi with replicas to new vCenter server and continue replication jobs?
ESXi(s) with original VMs were switched to the new vCenter earlier and I was able to continue replication, now it's the second part.

By 'continue' I mean keep existing restore points in place and create another one when the job is started.

Thanks in advance.

Best Regards,
Wojtek

[PTide]

Wojciech,

Please check this KB and feel free to contact support team to request assistance.

Thank you

[wojciech.bajorek]

I saw this KB and I read description couple of times but... it seems that it's not entirely true.
That's why I would like to know the real situation. Did you manage to 'continue'?

[PTide]

It's not possible to change vCenter and keep replica restore points as all information about snapshots is kept in vCenter database. You can map a replication job to reuse an existing replica (restore points will be deleted as well).

Thank you

[wojciech.bajorek]

It's not possible to change vCenter and keep replica restore points as all information about snapshots is kept in vCenter database.

Hm? Really? Replica restore points - aren't they just snapshots with additional information in Veeam database? vCenter is not needed for snapshot operations, it's rather ESXi role.

Based on my limited knowledge you do not save anything in vCenter database, but you store everything in VBS dedicated database.
IMO, this whole operation is about keeping consistency in Veeam DB. What is the problem here?

[PTide]

Replica restore points - aren't they just snapshots with additional information in Veeam database?

Correct, though vCenter keeps information about snapshots. For example an id mismatch can cause issues with reverting.

When you move to another vCenter all your VMs' morefIDs get updated thus Veeam can't see VMs and replicas anymore. The tool I gave you the link to works smoothly if you need to change morefIDs when migrating, however with replicas things might be more complicated so I think that you really should contact support team.

Thank you

[wojciech.bajorek]

That's why I think the whole operation should be doable. Without this tool I can map replicas using GUI but I will loose all restore points.
However your tool updates morefIDs with the old IDs so VBS sees them as the old one and should continue replication.
Also this is something you claim in KB.

Yes, I contacted support but after preparations they started to claim that this is not possible...
Logic (+other sources like forum or KB) says something completely different.

[PTide]

Yes, I contacted support but after preparations they started to claim that this is not possible... Logic (+other sources like forum or KB) says something completely different.

If you believe that support engineer is wrong you can use the "Talk to a manager" option to escalate the case and share you doubts with a higher tier engineer.

Thanks

[wojciech.bajorek]

If you believe that support engineer is wrong you can use the "Talk to a manager" option to escalate the case and share you doubts with a higher tier engineer.

So, I'm not sure - is it doable or not?
KB says something else, you are not sure.
Other people did not share their experience yet.

I'm confused. Many people migrated their environments to new vCenter servers, many of them changed from Windows based VC to VCSA.
Can you afford to lose all restore points?

[PTide]

So, I'm not sure - is it doable or not?

It is, theoretically. Replica's snapshots are dependent on each other and have unique morefids that are also subjects to change if you move to another VC. In order to let Veeam continue replication from where it had ended before the VC migration occured you need, at least, to change all replication related morefids so that they match the original morefids, besides, I believe that other pitfalls are very likely to exist. That is why I suggested you to escalate the support case to figure out whether it is possible to achieve what you want to. The other (and easier) way to keep restore points intact is to create another replication job and let old replica stay until the new one reaches the desired amount of restore points.

Can you afford to lose all restore points?

That depends on whether you have both backups and replica or just one of those.

Should you choose to keep working with support team please post your case ID in this thread.

Thanks!

[wojciech.bajorek]

It is, theoretically. Replica's snapshots are dependent on each other and have unique morefids that are also subjects to change if you move to another VC. In order to let Veeam continue replication from where it had ended before the VC migration occured you need, at least, to change all replication related morefids so that they match the original morefids, besides, I believe that other pitfalls are very likely to exist. That is why I suggested you to escalate the support case to figure out whether it is possible to achieve what you want to. The other (and easier) way to keep restore points intact is to create another replication job and let old replica stay until the new one reaches the desired amount of restore points.

That's unfortunately impossible as I simply don't have such amount of storage for replicas and it's a nonsense to buy 100TB+ storage unit for vCenter migration...

That depends on whether you have both backups and replica or just one of those.
Should you choose to keep working with support team please post your case ID in this thread.

Sure: 01797618

[PTide]

That's unfortunately impossible as I simply don't have such amount of storage for replicas and it's a nonsense to buy 100TB+ storage unit for vCenter migration...

I agree with you. As a possible workaround I can suggest you to use a pre-job script to automatically delete the oldest restore point from the old replica every time the new job starts.

Thanks