Replication Job & VM UUID/MAC address conflict

[RumataRus]

Every time I execute a replication job of a VM I see errors in Veeam Monitor: "VM instance UUID conflict" and "VM MAC address conflict".
Could Veeam Monitor be smart enough to do not show these alarms?

[Vitaliy S.]

Hello Dmitry,

Yes, it is already smart enough

You should navigate to Alarm Management, click on the alarm you want to suppress during this replication job, open alarm Properties -> Suppress tab and choose "Suppress when certain task is performed: Veeam backup activity".

Should help, please let me know how it works for you.

Thanks!

[RumataRus]

Cool!
Indeed I have not read Veeam Monitor Documentation yet because I study Veeam Backup & Replication now.
Veeam Monitor is the next one.
Thank You!

[pcrebe]

Hello,
...but may i know what does errors means?
Are they normals?
Thanks.
Carlo

[RumataRus]

By the way, I have encountered with a weird situation.
In spite of choosing "Suppress when certain task is performed: Veeam backup activity" the above-mentioned alarms is triggered for replica of certain VM every time when replication job is running.
Why?

[RumataRus]

...but may i know what does errors means?

You should navigate to Alarm Management and choose alarm name in the right pane.
In "Alarm Details" section there is rather detailed description.

[Vitaliy S.]

Yes, these events are expected during replication jobs.

In spite of choosing "Suppress when certain task is performed: Veeam backup activity" the above-mentioned alarms is triggered for replica of certain VM every time when replication job is running.
Why?

I guess this happens due to the fact that those events are not acknowledged as events triggered by Veeam replication job. We correlate Veeam backup activity based on snapshot creation/deletion events. That said, we should probably add this event to exclusion list as well. Thanks for the feedback.

[RumataRus]

HI, Vitaliy!
By the way, the same happens if SureBackup Job runs. Additionally error "Heartbeat is missing for VM" appears.
Also list of verified and deleted VMs grows (see screenshots please http://webfile.ru/5137135).
Best regards, Dmitry.

[Vitaliy S.]

Those alarms are triggered by certain events from vCenter Server, not sure we'll be able to trace the initiator of these events in order to suppress them in Veeam Monitor. I need to discuss it with our dev team.

You may want to change the timeout settings for missing tools. In order to do that just navigate to Alarm Management and edit the corresponding alarm rule parameters.

As for the list of verified VMs that continue to grow, please contact our technical team to investigate this behaviour.

[Alexey D.]

Dmitry,

Actually, "Heartbeat is missing for VM" alarm is generated by Vmware tools when a VM is being started with SB job. This is a known behavior of tools: sometimes they return 'false' even if VM is up and running.

[RumataRus]

As for the list of verified VMs that continue to grow, please contact our technical team to investigate this behaviour.

I just want to say that it would be reasonably to delete these temporary VMs automatically after executing SureBackup Job.
It is not error and I have no cause to contact your technical team.
Regards, Dmitry.

[Alexey D.]

Normally such kind of VMs are removed automatically. That's why we are advising to contact our tech support

[RumataRus]

Actually, "Heartbeat is missing for VM" alarm is generated by Vmware tools when a VM is being started with SB job. This is a known behavior of tools: sometimes they return 'false' even if VM is up and running.

I see, thank you!
But what about errors "VM instance UUID conflict" and "VM MAC address conflict" that appear during SureBackup Job?

[RumataRus]

Normally such kind of VMs are removed automatically. That's why we are advising to contact our tech support

Oh, I did not know it!

[Alexey D.]

"VM instance UUID conflict", "VM MAC address conflict" - these are also expected, let me eplain why:
temporary VMs which are created in virtual lab are exact copies of original, production VMs. Thus they have same ID and MAC - so when registered in inventory, you get these alarms.

[RumataRus]

Is it possible to suppress them as "knows events"?

[Alexey D.]

You may not want to add this as "known event" because in this case you might skip a real 'problematic' situation.
You can just exclude the corresponding alarm.

[pufferdude]

[merged]

I have Veeam Monitor 5 monitoring my vCenter environment, and every time a replication occurs (in this case, every 2 hr) two alarms are generated:

VM instance UUID conflict
VM MAC address conflict

Because these are a "normal" consequence of replicating a VM via Veeam B&R, I would like to suppress them... so I went into those alarms and looked at the Suppress tab, and chose "Suppress when certain task is performed: Veeam Backup activity" but this has NO effect on the triggering/reporting of these errors that recur every two hours during my VM replications.

Is this supposed to work, or did Veeam forget to add a "during Veeam REPLICATION activity" setting to the Suppress tab?

[bwestover]

[merged]

I have a handful of replicas, created with Veeam Backup and Replication. These are detected as having UUID and MAC conflicts in monitor.

Is this intended behavior?

[bwestover]

Ok, I see. Thanks for the merge. So "yes" would be my answer

I will simply exclude my replica VMs from this alarm. Thanks.

[stevenrodenburg1]

[merged]

Hello,

When B&R creates a replica VM, the same MAC-Adress is used (which is good).

Veeam Monitor however...
...starts yelling because of this.

As Monitor is B&R aware, it would be very nice if Monitor could exclude the "VM Mac Address Conflict" alarm automatically from replica machines. This saves annoyance and labour at every new customer when setting up replica jobs (especially when there are a lot of them).

Cheers,
Steve

[Vitaliy S.]

Hi Steven,

Currently there is no way to distinguish replicated VMs from ordinary ones, but I'm investigating possibilities of implementing deeper integration between B&R and Veeam ONE. Thanks for the feedback!