Description of problem: Currently, if you request MAC from pool, return it, and request again, you will always end up with same mac. This way the next guest created will most likely use a mac address witch was assigned shortly before. This behavior can cause numerous problems in DHCP and ipv6 addressing if the the record was not cleaned up in DHCP; for instance you will not be able to create any more hosts in foreman. We should delay reallocation of the MAC. Version-Release number of selected component (if applicable): all How reproducible: always Steps to Reproduce: 1. In Foreman, create a host using ovirt compute 2. Delete this host in ovirt, not in foreman 3. Create a new host in foreman using ovirt compute Actual results: Host creation fails because of DHCP exception Expected results: Host is created Additional info: This was discussed on the ML, mmucha suggested: when looking for available mac in pool, we iterate through available ranges selecting first one with some available mac: org.ovirt.engine.core.bll.network.macpoolmanager.MacsStorage#getRangeWithAvailableMac and select 'leftmost' available mac from it: org.ovirt.engine.core.bll.network.macpoolmanager.Range#findUnusedMac I understand your problem, we can either a) impose some delay for returning macs to pool or b)randomize acquiring macs, but we should as well specify, how should system behave, when there are not sufficient macs in system. Since when there are small amount of macs left, a) will block other requests for mac while there's no need to do so and b) will return same mac anyways, if there's just one left. And even worse, with low number of available mac (for example 5) and randomized selection it may work/fail unpredictably. Maybe more proper would be creating new method on mac pool, requiring 'mac renew/replace' — that's the actual usecase you need; not delaying/randomizing. You need different mac. Method like "I want some MAC address(es), but not this one(s); Returned mac addresses would be immediately available for others, and search for another mac can sensibly fail (this mac address cannot be replaced, there isnt another one)
I remember in the past we've discussed the option of looking up the next MAC in a range once from the start and once from the end of the range.
that will not work if there's no mac left, and will work unpredictably if there's very few mac left. (notice that you can acquire multiple macs at once). replaceMAC and replaceMACs is better approach I believe, since this is different usecase than acquiring them for the first time.
Verified on - 3.6.5-0.1.el6
Maybe this should be a new RFE but could it be possible also generate first MAC pool somehow randomly? We are using RHEV for production and oVirt for testing but with the same vlans on booth of them and both installations uses by default the same MAC pool. It was really nice debugging to find-out why one (two) of our vms has strange connectivity issues...
(In reply to Jiří Sléžka from comment #4) > Maybe this should be a new RFE but could it be possible also generate first > MAC pool somehow randomly? We are using RHEV for production and oVirt for > testing but with the same vlans on booth of them and both installations uses > by default the same MAC pool. It was really nice debugging to find-out why > one (two) of our vms has strange connectivity issues... we can do that. But I'm worried, that allocating first mac in random fashion will solve your problem only with some probability. I think it should be solved in a way, where it's impossible to have unexpected problems due to MAC address conflicts. Can you elaborate more about your problem? Why it's not possible to use REST call to alter mac pool ranges of one deployment? Ie. why you have to use default setting on both deployments?