2:19 p.m.
On 07/02/2013 14:21, Muli Salem wrote:
----- Original Message -----
> From: "Mike Kolesnik" <mkolesni(a)redhat.com>
> To: "engine-devel" <engine-devel(a)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.
mac pools per network are a good feature, but i would still warn on
duplicates. mac's in general are supposed to be unique in a DC, not only
in a single layer 2 network (i.e., one checking a switch mac table isn't
expecting to find different sources for the same mac address).
so +1 for the feature, but -1 as solution for this problem.
> 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.
+1 on importing in unplug mode and enabling this check on plugging
even better if we could detect at import time with candoaction and let
user choose if to 'generate new 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(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
_______________________________________________
Engine-devel mailing list
Engine-devel(a)ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel