[Engine-devel] Import/snapshots duplicate MAC support

[Muli Salem]

----- Original Message -----
> From: "Mike Kolesnik" <mkolesni at redhat.com>
> To: "engine-devel" <engine-devel at ovirt.org>
> Sent: Wednesday, 6 February, 2013 8:13:11 AM
> Subject: [Engine-devel] Import/snapshots duplicate MAC support
> 
> 
> 
> Hi,
> 
> The current situation dictates that if the configuration value
> AllowDuplicateMacAddresses
> is set to false (this is the default setting), then we block import
> or switching snapshots where
> a MAC address in one or more of the snapshot/ovf's virtual NICs is
> already used.
> 
> Given that we don't currently give the admin any option to select
> otherwise, I'm not sure
> that's a very robust behaviour..
> First of all the MAC address should be unique per network and not in
> the whole system (like
> it is currently).
> Furthermore, as long as in the same network there are no two virtual
> NICs running with the
> same address, it is not such a bad situation.
> 
> Therefore, I would like to propose a couple of solutions (from
> backend perspective):
> 1. Keep blocking.
> 2. Keep blocking but fix the mac pools to be per network basis.
> 3. Don't block, and allow duplicate MACs in these scenarios, but
> block on activating a NIC
> with duplicate MAC address. Warn the user that the NIC is with
> duplicate MAC, and
> perhaps even unplug or unwire it so that it would be obvious that
> it's using someone else's
> MAC.
> 4. Don't block, and give the problematic NIC a new MAC from the pool.
> 
> Solution 1 is obviously not the greatest (hence this email).
> In my opinion, 4 is sort of a cat in a bag, since I'm not sure
> changing the HWADDR for the
> guest OS is really a good idea.
> Solution 2 would be nice going forward, but it just reduces the
> chances of an admin to come
> across this situation and doesn't solve it entirely.
> Hence, I would favour solution 3 which seems to solve the problem and
> allow the admin to
> choose what to do.
> 
> Please voice your opinion, or propose an alternate solution.

Another solution would be to perform the action without adding the problematic vNic, and notify the user about it.

Overall, I am in favor of solution 3 as well.

> 
> 
> Regards,
> Mike
> 
> 
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>