VM moved to new vCenter

[veremin]

Based on my understanding of the algorithm, the tool should address that use case as well, because in a nutshell the situation is not different - VMs got new MorefIDs assigned. Thanks.

[bahooo]

Hi,
We have more than 50VM in 3 hosts in a VCenter.
We are usually doing power off servers because of maintenance. But, after I switched to VM, before power off host, I moved 15 VMs to other host. But, after that, Veeam began not to backup data of that VMs. As I quick read from some of web site, I should add VMs to backup job again, and backup job should backup full.
But I cannot imagine in Huge Companies like having more than 200VMs or more.
So, I have found some SQL command to create a script but, it looks like so manual. Hopefully, Veeam has a solution and make my day.

thanks.

[Mike Resseler]

Hi Bahadir,

I might misunderstand you but are you saying that when you vMotion a VM to another host Veeam doesn't backup the VM anymore? How are the objects been added to the backup jobs. Via vCenter or via a standalone host?

If they are added through vCenter, there should be no issues with vMotion

Thanks
Mike

[dellock6]

Sounds indeed like you added VMs from the single host. The best practice is to add VMs from vcenter, so that Veeam can use the vcenter morefID (the identifier of a VM) which doesn't change after a vmotion. ESXi IDs are recreated each time a vm is registered in a host, like after a vmotion. If there is vcenter, we use vcenter IDs instead of ESXi IDs.

[VladV]

Will this tool need to be updated to support VCSA 6.5 when it will be released?

I am asking because we usually go with a full reinstall of vCenter when major releases take place thus losing Moref IDs.

Thanks

[veremin]

Will this tool need to be updated to support VCSA 6.5 when it will be released?

It's something we'll need to test, once 6.5 goes GA. Thanks.

[aman4God]

I have a Veeam implementation right now that spans two environments, one 5.5 and one 6.0. We have been trying to gracefully migrate machines in chunks between environments by sharing storage, shutting them down and then bringing them up in 6. I am not a VMware expert, so forgive me if I am missing the technical details of everything happening there. The problem is that this is taking too long... We want to perform more mass migrations, but need to ensure we don't overwhelm the storage with Veeam backups as a result of changing the Server ID on all the servers at one time and creating mass full backups.

This is where my questions come in:
Is there a way to do this without changing the Server ID on the quests?

If the Server ID changes will it cause a full backup or is Veeam smart enough to roll with it?

What is the recommended method for migrating in bulk servers between environments?

[foggy]

VM ID change results in a full backup. However, you can look at the re-mapping utility discussed in this thread and check whether it is applicable to your scenario.

[northeast100]

Has anyone gone through the new vCenter Migration Toolkit to bring their Windows based vCenter to the SUSe/Postgres db vcenter(https://my.vmware.com/group/vmware/deta ... rPId=12934)and have veeam still able to backup the VM's with keeping all ID's etc? Very curious as we're thinking of doing this. I'm sure their would be some veeam re-config due to a new vcenter name, but we're curious if veeam would get confused by thinking all the VM's were new.

Thanks.

[veremin]

Most likely, you will need to leverage the tool discussed in this thread, so that, no new full backups are created after migration. Thanks.

[Carko]

For anyone in the similar situation, I would like to report that the tool does not work when migrating machines from standalone ESXi hosts to vCenter Server.

Although it does not report an error, it simply does not find any source VMs so the resulting migration task file is empty.

[foggy]

Yes, I'd expect the tool to be tailored for vCenter to vCenter migrations.

[douglas.carson]

Hi Guys,
I am going to be building a new vCenter and want to move my hosts to this new vCenter.
I am currently performing backups and replications(replicas are in the same VC but clusters are in different DCs)
What is the official way to migrate to the vCenter. I know there is the migration tool but this states it is not supported by support.
The second thing is how will the migration affect by replicas?

Thanks

DC

[foggy]

Hi Douglas, you can review this thread for the answers. Basically, after migration you would need to re-add VMs to the jobs, since their IDs will change. This will result in full VM data read during the next job run. If you want to avoid that, you can use the mentioned migration tool to match the new IDs with VMs stored in Veeam B&R database.

[csinetops]

I am planning on upgrading my VCenter version from 5.5 to 6 tomorrow and ESXi version to 6 on all my hosts in the next few weeks.

Anything I should be aware on the Veeam side post upgrade? I assume that all I need to do is remove the old VCenter server from Veeam and add the new one or will that mess something up?

I did read that I could keep the same VCenter name as long as I rename the current VCenter VM name in VCenter before I run the upgrade. Thoughts?

[foggy]

If you're planning migration to a completely new instance of vCenter, then VM IDs will change, so I recommend to review this thread for consequences and ways to eliminate them. In case of in-place upgrade, you're good to just continue running your jobs normally.

[loller]

HI All,

yesterday i've disinstalled vcenter from a VM and re-installed a newer version on the same VM

the ip dind't change , the FQDN didn't change, credential didn't change

after that , on veeam console , we check that veeam could correctly access the newer vcenter . after accepting the certificate everything seems to be good.
we also did a test backup job of a single VM and it ended good.

on this morning we noticed that many of our backup jobs gone bad and shows error.
but the strange things is that VM moved from a backup job to another.

i did a rapid researc and find that changing vcenter could modify the machine identification used by veeam :

now the question is : i could undenstard that veeam may not found VM after changing a DB , but is possibile that VM auto-move from a job to another? and , could this happen just for some VM (many other keep staying in their job)?

[foggy]

Hi Luca, you're totally correct, the reason of this behavior is changed VM IDs. The "move" between the jobs is also possible in case one of the VMs got the same ID in new vCenter that the other VM had in the old one. To address this issue, you can use the matching utility discussed in this thread above. Thanks.

[arthur.reed]

We use VEEAM Backup and Replication for offsite cloud storage of our backups. I am running into a problem where my VEEAM installation is apparently trying to create a full backup on on my cloud storage after a new vsphere host installation.

So during our hardware refresh I have built a new vsphere server using the appliance rather than a windows install on a physical machine as we had in the past. I created new VM hosts and added them to this new vsphere instance. I then disconnected my old hosts from the existing vsphere installation and then added them to my new vsphere. I then migrated the VM's from the old hosts to the new using the new vsphere and have decommissioned the old hosts and vsphere. So my VM's are now running on the new hardware.

Last night I ran my first offsite backup job and after 9 hours it had only gotten 23% through one VM and had copied 123GB to the cloud storage. So it appears to be trying to create a new backup. I noticed that during our local backup to disk it did this but I didn't consider it a big deal since it was a local transfer. Obviously I don't want to have to transfer TB's worth of data to the cloud. Is there anything I can do? It was the same exact cloud backup job. It looks like something about the VMs changed to VEEAM when I migrated to the new vsphere installation to make it think these are different VM's than where backing up prior.

[Vitaliy S.]

Arthur, when you re-register VMs in the inventory, they receive a new ID from the vCenter Server and are treated as new VMs. Please review this topic for further info.

[arthur.reed]

Thank you Vitaly for the information. I have just opened a case with VEEAM support to help with the ID migration tool. I just don't feel comfortable doing it myself and would rather work under the supervision of the experts.

[Vitaliy S.]

You're welcome. The migration tool might not always be the option depending on the configuration of the backup and backup copy jobs, so let's see what our team can do for you.

[arthur.reed]

Spoke with support today and overall it did not sound like he had a lot of experience with this process and said he would forward this to a cloud specialist. I continued on with the migration tool but when I run it I get the error:

Code: Select all

------- Veeam VM Migrator Tool Started -------
Input arguments: preparemigrationtask bc-rmadmin.barnhillcontracting.com_old rmvsphere1.barnhillcontracting.com
Building DbObjects to VMs mapping started
Error: Column 'object_name' does not belong to table .
See log for more details
Error: Column 'object_name' does not belong to table .
See log for more details
Error: Column 'object_name' does not belong to table .
See log for more details
Getting VMs from rmvsphere1.barnhillcontracting.com
Got 26 VMs from rmvsphere1.barnhillcontracting.com
Building DbObjects to VMs mapping finished
Writing migration task into file started
Writing migration task into file finished: created task file - bc-rmadmin.barnhillcontracting.com_old_to_rmvsphere1.barnhillcontracting.com_migration_task

The migration file does not list any VM's in it. Looks like it is not able to list the VM's from the old server but is able to connect to the new one and see the VM's on it.

[arthur.reed]

Just got a response from support:

"Here's my response from what I'm seeing in the notes: VMware does not support changing MoRef IDs manually, so neither do we. You'll notice that, even with our conversion tool, it is emphasized that we offer it as a convenience and do not support it.

Once that MoRef id has changed, you will have to re-add the VMs into the job. As such, the original backup job will run an active full. and the Backup Copy job will run a full. There really is no way around this."

So it looks like I'm screwed and the only thing I can do is pay for a reseed. I replied that I wouldn't think that you were changine the MoRef ID's on the VM but rather changing them in the VEEAM database to map the new ID's.

[arthur.reed]

Looks like I have struck out, VEEAM support refuses to help me citing the statement that this is provided as is.

"What you are talking about is as such:

http://www.virtuallyghetto.com/2011/11/ ... hange.html

When MoRefs change, to assure the information is changed in our DB, we remove the VM, click add, click refresh, re-add the VM and finish out. This adds the MoRef ID in Veeam and runs the job normally.

I must point out that, in bold, on the kb for the tool, is the following:

"Please note that this utility is provided as a courtesy, and is not officially supported by Veeam Technical Support. Use at your own risk."

I'm sorry to be the bearer of this bad news. As always, if you have any questions or concerns, don't hesitate to ask."

[veremin]

If I remember it correctly, one of the prerequisites the said utility has is that you must not run jobs against new host. Otherwise, the tool would not be able to get list of VMs residing on the old host. This seems to be happening in your case. Thanks.

[dguidry]

So, I'm now dealing with this same issue as well. I upgraded vCenter 5.5 to 6.5 (a clean migration, not an upgrade) and was disappointed to find all of my backup jobs were attempting to run active fulls. Now that I've gone through this thread and done a bit of Googling, I understand the issue, but unfortunately the migration tool Veeam provides is not working. I ended up receiving the same error messages that arthur.reed encountered:

Error: Column 'object_name' does not belong to table .

when running the preparemigrationtask operation. I have contacted support and they told me that the migration tool has not yet been updated to support the changes in the vCenter 6.5 database. So, we're kind of stuck now which means I'll be spending my weekend babysitting ALL of my backup jobs through active fulls and hoping I don't run out of disk space.

It would be awesome if they would just build that functionality directly into the Veeam B&R system to be able to handle MoRefID changes, given that the IDs can change rather easily. I can't imagine what kind of nightmare this must be for an organization with hundreds of VM's, especially when you're dealing with copying your backups over a WAN. This is probably coming up a LOT over the last year now that the VCSA has become more robust and many organizations (such as ourselves) have begun migrating away from the Windows version which often requires a clean migration. We had issues with VMware's migration Fling when we went from Windows to VCSA, so I'm sure many others have also.

TLDR: vCenter migration tool doesn't support vCenter 6.5 yet, so your mitigation options are very limited!

[dgomes]

If I remember it correctly, one of the prerequisites the said utility has is that you must not run jobs against new host. Otherwise, the tool would not be able to get list of VMs residing on the old host. This seems to be happening in your case. Thanks.

Sadly people do not know this problem has occurred until after the backup job ran and encountered problems, so you pretty much have to get screwed once to know of this limitation. We always tell our customers this will happen in advance when we know they will be setting up a new VC.

[veremin]

I've asked support team to state this prerequisite explicitly. Also, for now we will add a note regarding vSphere 6.5 not being supported by the utility.

[oliverL]

Since the search didn't found anything with "tag"

Has anyone used vmWare Tags as a selection for the backup jobs?

Can we except the same behavior if the hosts with the VMs are on a new vCenter (no upgrade Installation vCenter 5.5 to 6.0 ) (and still have their corresponding tags?) or will Veeam work flawlessly since it needs to build the vm list anyways?