Post vCenter 5.5 upgrade to 6.0 - Notes

[jtupeck]

Hello all....

I just got done with a vCenter 5.5 to 6.0u3 upgrade and have found some issues with Veeam integration, when using vCenter Tags to drive your backup jobs.

As a bit of an overview:

• We use two vCenter Tag categories to drive both backup and retention; they are called Backup Policy and Data Retention Policy. Each VM we protect with Veeam gets one Tag from each category.
  The Backup Policy category has 5 available Tag classifications: Mission Critical, Business Critical, Business Important, Business Supporting and Business Other.
  Data Retention Policy has 3 Tags: STR - Short Term Retention, MTR - Mid Term Retention and LTR - Long Term Retention.

• Backup Jobs are set up by adding the appropriate Backup Policy Tag and all relevant Veeam BJ settings to pull the information from production infrastructure. Pretty straightforward.

• Backup Copy Jobs are set up by adding the appropriate Data Retention Policy Tag from 'Infrastructure' and all relevant BCJ G/F/S retention settings that apply to said policy. These jobs are pointed at the backup job repositories for source data, so we only hit production one time and all restore points are the same. Also fairly straightforward, I believe.

• We also use a Tag for Replication Jobs. These are less policy driven, more inclusive of related VMs.
  Replication Job Tags vary in nature, but contain VMs that are related and that are started together with Failover Plans

All of this works on a nightly basis and works VERY well. When we add a new VM, we tag it appropriately and then the VM is included in the appropriate jobs. After we upgraded to vCenter 6, I performed a rescan of the vCenter appliance in the Veeam console. We use a DNS alias for vCenter, so it just picked it up as normal and scanned just fine. Credentials were ok, I can see the VMs, etc. All good. When I ran a test Backup Job, though....All the VMs reported as having been removed from the job. (i.e. the message in the job details said : "[Server Name] is no longer processed by this job. Make sure this change is intentional.") The change was NOT intentional, so I began to investigate.

I edited the job, reviewed the 'Virtual Machines' tab and the vCenter Tags appeared as expected. When I clicked 'Recalculate' to recalculate the storage size of the VMs, the results were 'N/A'. It was not seeing any of the tagged VMs. The solution was simple; I clicked 'Add', then navigated to the 'VMs and Tags' view and readded the appropriate tag for that job. The sizing calculations came back correct and I edited my 'Exclusions' where necessary, then deleted the 'old' Tag from the list, where 'Size' reported as 'N/A'. A rerun of the job worked as expected, with CBT functioning as normal, thankfully. I tested the Backup Copy Jobs and the same solution/workaround was needed.

This is where it gets interesting. Because of the above testing, I figured "Ok...its just an issue where the vCenter Tags must have some new unique ID, or something and all my jobs are going to need to be edited." This proved to be the case for Backup and Backup Copy Jobs....but NOT for Replication Jobs. My Replication Jobs appear to be working JUST FINE!

Now, my question is, WHY? Why do the same vCenter Tags work for Replication Jobs, but not for Backup and Backup Copy Jobs? Is this a known issue? Did I discover something useful and new? If other environments are using the same setup as we are, then they would likely have the same experience as this. With this in mind, I figured I would post here in the Forums and see what other experiences have been and/or if this is something that is known to Veeam Support and/or could be resolved. Please let me know if there is anything I can do to help in the provision of logs, etc. by opening a case, if anyone at Veeam is interested in seeing more details.

Thanks!

[jmmarton]

This won't help, but as an FYI when I upgraded from 5.5 to 6.5 my backup jobs which use tags continued to function normally. I wonder if there's an issue with 6.0? It would be worth opening a ticket with Veeam support to look into this further.

Joe

[mwvme]

Hello Joe,

You should talk to support about this. I think this may be related to a the fact that VMware does migration style of upgrades. Which may in fact produced different UUID for the VM's and that might impact all of this. I would have guess not since you are using tags, but I am not sure. But if so Support could help and if not, then we can learn and maybe do something in the future to avoid this.

Michael