My biggest Veeam complaint (pls think about)

[Starman]

I have a small environment, 5 servers, 60ish virtual machines however I'm running a lot of heavy VMware apps such as View, vCops and SRM. I constantly have to change and alter my cloud. I'm constantly having to add and remove hosts to fix various issues that come up. This means that at least once a month I have to either completely rebuild my Veeam backups on all 60 Virtual machines or go into each one and reassign the broken VM link to the new location which causes Veeam to do a full backup. This leads to days and days of dealing with major backups full time. I spend a LOT of time having to dink around with Veeam to keep it running due to this.

I really wish you guys could be a bit less strict on the licensing side and design some intelligence into Veeam to recognize things such as a possible removal/re-adding of a host. I think Veeam in general just needs more intelligence built in for these things.

[Gostev]

This has nothing to deal with Veeam licensing... you are simply performing operations that change unique VM IDs, the parameter used to uniquely identify and track VMs in VMware. There is no other reliable way for matching VMs that could be automated. Virtualization makes it way too easy to create multiple copies of the same VM, and they will all have exactly identical settings.

I would recommend that you review your procedures of making changes to your infrastructure. For example, before removing a host from a cluster, VMotion all virtual machines to other hosts in the cluster. This will allow you to remove the host safely, without losing unique VM IDs.

[averylarry]

Gostev -- the equivalent of seeding for a backup job would/could perhaps mitigate some of this frustration . . ? I know that's what I do when I get new VM id's for whatever reason -- at least for replicas I can just re-map the replica seed and the metadata is regenerated. Maybe that's not really any more efficient, though, if you have local/fast backup source/destination.


Starman -- if you indeed have legitimate needs to do things with your cloud that lead to VMware assigning new IDs, then I think you're just going to have to live with this type of issue. I tend to doubt that Veeam is the only product that has quirks when you do this. Indeed - your v-nics probably even get new MAC addresses . . . You probably know this stuff, but just in case . . . maybe you could find a more "VMware friendly" way to do what you need. Add/remove hosts should have no affect on Veeam if you're using the same vCenter server, for example. Moving datastores has no affect. Basically, just avoid removing any VMs from your vCenter inventory and the rest should take care of itself.

[Gostev]

Ted - you are right... you are essentially talking about manual matching, which is fine for one-time event like replica seeding, but will not resolve his main complaint (having to manually update all jobs once a month).

[veremin]

I’m wondering whether virtual machines are added as individual objects or you’re using containers.

If they are added as individual objects, it might be worth using some PS script that will be executed once a month, after crucial changes have taken place. This script will get the list of VMs present in a job and compare their unique IDs with the ones that are assigned in vCenter. In case they don’t match, the script will delete the corresponding VM from the job and add the one with the up-to-date ID, instead.

Hope this helps.
Thanks.