On 07/02/2013 14:21, Muli Salem wrote:
----- Original Message -----
From: "Mike Kolesnik" <mkole...@redhat.com>
To: "engine-devel" <engine-devel@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@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
