[Engine-devel] Import/snapshots duplicate MAC support

[Itamar Heim]

On 10/02/2013 08:24, Mike Kolesnik wrote:
> ----- Original Message -----
>> On 02/08/2013 02:19 PM, Itamar Heim wrote:
>>> 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'.
>>>
>>
>> I would go for introducing a new parameter to import vm action for
>> allocating a new mac address if it is in use. Its default value
>> should
>> be set to false, so the user is aware of his intention to replace the
>> vm's mac addresses. Else (if user decided vm should be imported with
>> the
>> exact mac addresses) block the operation on can-do-action with the
>> list
>> of mac addresses and the vm names which own them so the user can take
>> different actions (e,g, free/replace these mac addresses).
>>
>> The user should be aware the change of import behaviour when the
>> allow
>> duplicate mac addresses is enabled. In which case even if the user
>> asked
>> not allocate new mac addresses for the taken one, the action will
>> succeed.
>
> In this case, I would say that the default value should be the same as the
> "allow duplicate macs" option.
> If the user chose to override the default, then we should act according to
> his will..

I wouldn't make a default value change based on the config for this. 
even for an environment that allows duplicate macs, it would be the 
exception, not the rule.

>
> This however solves only the import problem but not the snapshot switching
> problem, and in that case it's a bit more complicated to add a parameter..
> It is the reason I initially opted for a "backend only" solution which can
> solve both cases.
>
>>
>>>>> 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
>>>>>
>>>>>