<html><head><style type='text/css'>p { margin: 0; }</style></head><body><div style='font-family: times new roman,new york,times,serif; font-size: 12pt; color: #000000'>Hi,<br><br>The current situation dictates that if the configuration value AllowDuplicateMacAddresses <br>is set to false (this is the default setting), then we block import or switching snapshots where<br>a MAC address in one or more of the snapshot/ovf's virtual NICs is already used.<br><br>Given that we don't currently give the admin any option to select otherwise, I'm not sure <br>that's a very robust behaviour..<br>First of all the MAC address should be unique per network and not in the whole system (like<br>it is currently).<br>Furthermore, as long as in the same network there are no two virtual NICs running with the <br>same address, it is not such a bad situation.<br><br>Therefore, I would like to propose a couple of solutions (from backend perspective):<br> 1. Keep blocking.<br> 2. Keep blocking but fix the mac pools to be per network basis.<br> 3. Don't block, and allow duplicate MACs in these scenarios, but block on activating a NIC <br> with duplicate MAC address. Warn the user that the NIC is with duplicate MAC, and <br> perhaps even unplug or unwire it so that it would be obvious that it's using someone else's<br> MAC.<br> 4. Don't block, and give the problematic NIC a new MAC from the pool.<br><br>Solution 1 is obviously not the greatest (hence this email).<br>In my opinion, 4 is sort of a cat in a bag, since I'm not sure changing the HWADDR for the<br>guest OS is really a good idea.<br>Solution 2 would be nice going forward, but it just reduces the chances of an admin to come<br>across this situation and doesn't solve it entirely.<br>Hence, I would favour solution 3 which seems to solve the problem and allow the admin to<br>choose what to do.<br><br>Please voice your opinion, or propose an alternate solution.<br><br><div><span name="x"></span>Regards,<br>Mike<span name="x"></span><br></div><br></div></body></html>