[Engine-devel] Import/snapshots duplicate MAC support

[Itamar Heim]

On 07/02/2013 14:21, Muli Salem wrote:
>
>
> ----- 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.

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 at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel
>>
> _______________________________________________
> Engine-devel mailing list
> Engine-devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>