ESXi 6.0 U1b - VM MAC Conflict alarm on Veeam Replicas

[pjahnz]

Recently updated our ESXi hosts from 6.0 U1 to 6.0 U1b, now all of our Veeam replicas are showing a VM MAC Conflict alarm in vCenter that won't go away. Confirmed that the MAC addresses on the source and replica VMs are different (checked the properties of the network adapters in vCenter as well as the vmx config files for the VMs). The MAC conflict alarm appears whether using Veeam v8 or v9. Case has been opened with VMware. Has anyone else run into this?

[NightBird]

Same problem here after upgrading one of my customer vcenter from 6.0U1 to 6.0U1b
I simply disable the VM MAC alarm on the alarms definitions

[pjahnz]

Thanks, glad to hear I'm not the only one who's come across this. I had considered disabling the alarm, but since it didn't exist 6.0 or 6.0U1, it seemed like a bug in U1b that should be addressed.

[NightBird]

Before 6.0U1b I don't think the vm mac conflict alarm definition exist as part of default alarms definitions

Will check on a 6.0U1 vcenter

[NightBird]

I have check on 6.0U1, and this alarm isn't define

[Vitaliy S.]

Confirmed that the MAC addresses on the source and replica VMs are different (checked the properties of the network adapters in vCenter as well as the vmx config files for the VMs).

When VM replica gets registered, it does have the same MAC address, but then vCenter Server/ESXi host updates it with a new value, that's why you see this alarm being triggered.

[TroyResources]

Exact same error, ESXI Hosts in our environment mixture of 5.x and 6.x also mixture of V8 SP3 and V9, so this does really point to some issue with vSphere.
Applied the U1b to overcome issues related to CBT; however all replicas world wide showed VM MAC Conflict alarm.
VMware tech support said issues we related to Veeam; Veeam said this was an VMware issue.
Suffice to say only temporary resolution was to switch alarm off to quell remote administrators flooding my inbox.
This KB did not resolve any issue either http://kb.vmware.com/selfservice/micros ... Id=1024025
Veeam tech support had said, "What you are seeing is behavior by design to be honest. This is given the nature of a replication, as the VMX is cloned, which will contain a duplicate MAC address for a brief moment until it is properly updated in vSphere."

At the end of the day it's slightly disappointing to bug like this appear...

[mickeybyte]

I have noticed the same behaviour, however we are running ESXi 5.5. The alarms began when I upgraded my VCenter Appliance to the latest 6.0 build (the previous 6.0 build did not trigger this alarm).

It seems it has nothing to do with the ESXi versions, but with the VCenter version.

[postict]

Same issue when using Surebackup.
You get also MAC conflict warnings and when you check all MAC-addresses there doesn't seems to be any conflict.

[foggy]

Veeam tech support had said, "What you are seeing is behavior by design to be honest. This is given the nature of a replication, as the VMX is cloned, which will contain a duplicate MAC address for a brief moment until it is properly updated in vSphere."

At the end of the day it's slightly disappointing to bug like this appear...

I think the support engineer's answer you've quoted clearly explains this behavior, so I'm not sure why do you still refer as a bug to it. Seems that the latest vSphere update just enables the alarm, which was not defined previously, that's why you started seeing warnings for the events that simply went unnoticed before the update:

I have check on 6.0U1, and this alarm isn't define

[dspjones]

Just to throw my experience here as well.... I upgraded vCenter to 6.0 U1B on Thursday (all hosts are still 5.5 update 3). All my replicas now show mac conflict. So it would seem indeed this is a vCenter thing. Not esxi.

So is the correct response to this "problem" to disable that alarm? That doesn't seem like the right thing to do. If vsphere is supposed to update the mac after a few moments but the alarm is still being triggered, it would seem to me that it is indeed a bug. Probably not a Veeam bug, but definitely something Veeam could help inform VMware about with your partner status rather than us lowly users trying to get them to fix this.

[Vitaliy S.]

As a solution to this problem you might want to specify a resolving event for this alarm, so once MAC address is changed, you no longer see this alarm in an opened state. Will try to take a look at our labs to find out what rule/trigger can be specified to resolve this alarm.

[getzjd]

Same issue here .. updated vCenter from 5.5 u2 to 6 u1b. MAC address alarms on all replicas

[Vitaliy S.]

Jay, cab you please check out if you have any event that cab used as a resolving event for this alarm?

[B.F.]

Just noticed this myself after applying the vcenter and vsphere client updates.

I looked quickly and the replica and source VM MAC addresses are NOT the same.

Suggestions other than disabling the alert?

Thanks

[Vitaliy S.]

The alert gets triggered on the initial run, after the collision is detected, vCenter Server changes the MAC address of the VM that's why it doesn't match with the original one.

[B.F.]

Acknowledging and clearing the alarm only makes it come back after the next replication. Perhaps there's a way to have vSphere only check for MAC conflicts after replication is completed?

[Vitaliy S.]

Cannot find this option, but as a temporary workaround you can try to exclude source VMs from this alarm.

[B.F.]

OK I can try that. Maybe a Veeam feature request would be that Veeam changes the replica's MAC before it completes somehow in midstream? (If that is even possible.) It sounds like vSphere is able to check the replica MAC before Veeam has a chance to make the change.

[Vitaliy S.]

Unfortunately, Veeam cannot change MAC address of the VM, as it is the vCenter Server/ESXi host that manages that.

[B.F.]

So MAC changes to the replica is actually done / managed by VMWare? If so, time to pile on VMWare's forums?

[B.F.]

Don't know if this helps but we have a large VM that takes quite a while for the snapshot to be removed after replication is completed. I'm now seeing a replica of that VM with no alarms triggered while it's in "Remove snapshot" mode. I'm assuming as soon as it's done, the alarm with be triggered.

[Vitaliy S.]

So MAC changes to the replica is actually done / managed by VMWare? If so, time to pile on VMWare's forums?

When VM replica is created is should be identical to the source VM, after that VMware tries to resolve all conflicts and raises the alarm if it detects some collisions. Maybe there is a way to tweak alarm detection.

[mloeckle]

This worked for me. All our replica VMs end with the default suffix "_replica". So I added a Trigger Condition to each of the Alarm Triggers (VM MAC conflict, VM static MAC conflict). Value = "VM name", Operator = "does not end with", and Value = "_replica".

[Vitaliy S.]

Perfect! In Veeam ONE we have an ability to make exclusions for all replicas too.

[B.F.]

Adjusted our alarm...now we wait....

Thanks

[ITP-Stan]

Thanks mloeckle!

[lowlander]

Hi,

we are in the proces of upgrading our VMWare farm. When replicating between vSphere 5 and 6 we now receive an alarm on the target replica : VM MAC Conflict. Is this expected behaviour ?

thanks !

[PTide]

Hi,

Yes, that's an expected behaviour. Please review the thread to see possible solutions. Also this KB and this blogpost might be helpful.

Thanks

[lowlander]

Superb !

works fine

thanks