Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1269301

Summary:	RFE: Do not recycle MAC addresses immediately
Product:	[oVirt] ovirt-engine	Reporter:	Daniel Helgenberger <daniel.helgenberger>
Component:	RFEs	Assignee:	Scott Herold <sherold>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Meni Yakove <myakove>
Severity:	high	Docs Contact:
Priority:	high
Version:	3.5.4	CC:	bugs, danken, jiri.slezka, mburman, mmucha, myakove, sbonazzo, ylavi
Target Milestone:	ovirt-3.6.5	Keywords:	FutureFeature
Target Release:	3.6.5	Flags:	rule-engine: ovirt-3.6.z+ ylavi: planning_ack+ danken: devel_ack+ rule-engine: testing_ack+
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Enhancement
Doc Text:	Feature: Reason: In environment, where VMs are created and removed quickly, acquiring MAC addresses in smallest MAC available order may lead to situation, where there's MAC still used on network, but device using it is different than expected — other devices expects, that this MAC address belongs to some device which was here just moment ago. Result: MAC addresses are acquired in cycle. When getting MAC address from pool, pool marks position of last returned MAC, and next time will search for available MAC from this position. This will cause all other available MAC address are 'used' before reusing MAC address returned back to pool.	Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-21 14:40:40 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Network	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1066594

Description Daniel Helgenberger 2015-10-06 23:02:45 UTC

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)

Comment 1 Yaniv Kaul 2015-10-08 08:27:05 UTC

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.

Comment 2 Martin Mucha 2015-10-19 06:24:47 UTC

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.

Comment 3 Michael Burman 2016-03-31 06:50:29 UTC

Verified on - 3.6.5-0.1.el6

Comment 4 Jiří Sléžka 2016-03-31 20:32:06 UTC

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

Comment 5 Martin Mucha 2016-04-04 14:30:27 UTC

(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?