VB there must be a better way?

[beckhamk]

Dear Veeam,

You know I love VB that it breaks my heart to have to make a post like this. So I am hoping there is an easy fix for this or that this can be resolved in the future.

There absolutely has to be a better way to resync VB backup jobs and VMs on vCenter.

Let me explain, We have about 50 VB jobs setup and scheduled and that was working perfectly. But we upgrade to VCenter v4.0 over the weekend and ended up having to (not disconnect) but remove all of the hosts from a cluster and then re-add them. After doing this we found out that all of the VB jobs started failing with simular texts as:

Analyzing object "DNS3" (vm-22210), host "vc.xxxx.com"
Object "DNS3" (ref "vm-22210") was not found in hierarchy
There are no objects to backup

This happened because we removed the hosts and VB seems to track based on vm managed object id instead of the vm UUID. From what i can tell when you add a host with vms to VC it apparently renumbers the vm managed object id. So our vm DNS3 which was vm-22210 was now vm-143 after being readded, which caused VB to fail. We had to go through all 50 backup jobs and manually remove the vm and re-add them to each job. Very Painful.

I am no expert when it comes to the vmware api, but we have been developing with it, would it not be better to use the UUID of the vm to find the existing vms instead? As I dont believe the UUID will change when being readded to VC.

Thanks in advance....

[Gostev]

Hello Kyle, we are not using UUID for VM tracking on purpose, because it is not changing during VM restore. So potentially if you restore some VM more than once, you will end up having multiple VMs with same UUIDs in your environment. Reference ID is the recommended way to track VMs in VMware management application because it ensures uniquiness that is controlled by vCenter/ESX hosts.

On the other note, we do not recommend configuring backup jobs by individually picking VMs, and instead using containers (hosts/clusters/VM foldes). Doing this gives you dynamic scope and lets avoid this type of issues. Stuffing jobs with individual VMs is not too scalable approach from management perspective: you have to edit jobs each time when you add or remove VMs, or change anything in your environment. While this may be OK for small deployments, it becomes increasingly hard to do as the number of VM grows. I find that currently most customers choose to use VM folders to organize their jobs. Have you considered doing this?

Thank you!

[beckhamk]

We do not backup many individual vm's. We actually do them in batches of 3 or 4 and two jobs running at anyone time. Backing up at the hosts/cluster or even folder level would be a nightmare in our environment so that is not a solution for us. I just wish there was a better way to do this.