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

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

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