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