DUPLICATE_MAC_SEED

icompit

@DustinB Main reason is related with OS license costs... I agree that it would be easier to have single pool.

DustinB

@icompit gotcha, while I generally understand the reasoning behind this, it doesn't work like this practically.

If you're moving your VM's around from one host to another in an unmanaged environment, that would mean that the VM could run in multiple locations at once which would negatively impact your licensing costs.

Whereas if you have 1 pool, the VM can only be running on the singular pool once without you making any changes to that system.

Of course if you removed the NIC or sysprep'd a VM then it could run somewhere else, but those are fundamental changes to a given VM.

icompit

@DustinB

Look I have xs-node1 and xs-node2 as you can see DC1 running on node1 and have replica to separate, replica dedicated, SR at node2... DC2 running on node2 and have replica also to this replica dedicated SR.

Both xs-node1 and xs-node2 have only local storage NVMe for running VMs and xs-node2 have also ZFS pool for replicas.

When I'm trying to migrate DC1 to xs-node2 on NVMe SR I'm getting this DUPLICATE_MAC_SEED error.

Only one DC1 VM running across both xs-nodes...

icompit

@DustinB

Here is the backup job configuration:

KPS

@icompit
Did you ever solve this? I am having exactly the same problem...

icompit

@KPS
Unfortunate, no. I just replicate and avoid moving live VM on the same host, target for replication.

Tristis Oris

Can't migrate an XO VM to any pool because of this error.
You need to remove any CR copy that is halted to make migration work.

Pilow

@Tristis-Oris could you not temporarly change the CR VM Mac address on the VIF ?
problem would be solved ?

Tristis Oris

@Pilow no.

poddingue

I don't fully follow the mac-seed side of this, but a couple of things in the thread stand out. Tristis Oris's workaround looks like the practical unblock for now: removing the halted CR copy on the target host lets the migration go through, presumably because that replica VM is what collides on the mac-seed.
Since you, KPS and Tristis Oris are all hitting the same DUPLICATE_MAC_SEED migrating into a replica target, this feels like something worth a GitHub issue on xen-orchestra with your XO commit, the exact steps, and whether a halted CR copy is present each time.
It might also be worth a mention to @Team-XAPI-Network, since they'd know whether a CR replica is supposed to share its source's mac-seed.
I could be wrong on the mechanism, so take that with a pinch of salt.