Re: [Engine-devel] Import/snapshots duplicate MAC support

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(a)redhat.com&gt; >>> To: "engine-devel" <engine-devel(a)ovirt.org&gt; >>> 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.

>>> 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 >>> >>>