Description of problem: Customer uses third party solution for DNS and DHCP management of their networks and to facilitate provisioning of new RHEV guests by PXE booting and DHCP. Users create and delete environments quickly resulting in MAC addresses from destroyed guests being immediately re-used in newly created guests. After a guest is provisioned its MAC address, allocated IP address and hostname are pushed to third party network management solution. Immediately re-using MAC addresses that were in use seconds ago by other already destroyed guests causes issues with QIP DHCP server not refreshed in time and guests not being reachable until former ARP entries expire. Version-Release number of selected component (if applicable): rhevm-backend-3.2.5-0.49.el6ev How reproducible: Always. Steps to Reproduce: 1. Create a NIC. 2. Destroy the NIC. 3. Immediately afterwards create a new NIC. Actual results: NIC in step 3. has the same MAC address as NIC in step 1. Expected results: MAC addresses are not immediately re-used to prevent clashes and ARP issues. Additional info:
As a temporary workaround, if the customer is interested in allocating the MAC address to the VM's in a proprietary way he can use the custom MAC address field in the VNIC. By using this field the customer could guarantee the MACs won't be reused until the QIP is updated.
Michal - doesn't look like a very hard task to achieve (random allocation from the pool) - can I mark as a StudentProject and target 4.0?
there were some considerations/complications regarding the mac pool, not sure it was that simple(keeping a list of recently used MACs). Random would perhaps work good enough, though ultimately this is a network's group decision
Per mmucha, randomization is indeed simple.
(In reply to Dan Kenigsberg from comment #13) > Per mmucha, randomization is indeed simple. no, randomization would be ineffective and would not produce 'stable' behavior. Better approach was used, required behavior is already implemented. We're waiting for code review & possible merge. Check following for more information: https://gerrit.ovirt.org/#/c/49502/
Why was this moved to 3.6.z?
(In reply to Yaniv Dary from comment #17) > Why was this moved to 3.6.z? My product manager told me that this bug annoys many customers, and should be fixed early if it is not too risky.
Can you ack\nack this for 3.6.5?
Is the solution working well in the case of a single range, which I believe many customers have?
(In reply to Yaniv Kaul from comment #20) > Is the solution working well in the case of a single range, which I believe > many customers have? Yes, each range maintains its own startingLocationWhenSearchingForUnusedMac to make sure that an address is reused only after all its range peers have been reused. there are obvious early reuse if one of the ranges is almost full, though)
Verified on - 3.6.5.1-0.1.el6
no need to clone this bug, as it was already fixed upstream and verified in comment 22.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHEA-2016-1743.html