[ovirt-users] MAC address recycling

[Daniel Helgenberger]

On 27.09.2015 12:25, Martin Mucha wrote:
> Hi,
> 
> danken, I do not remember I saw such a bug. 
> 
> In 3.5 and 3.6 there was some changes in MAC pool implementation and usage in system, but order, in which macs are assigned remained unchanged. Yes, if you request MAC from pool, return it, and request again, you will always end up with same mac.
> 
> 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

Thanks clearing up this behaviour!

I would open an RFE?

> 
> 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)
> 
> M.
> 
> ----- Original Message -----
>> On Thu, Sep 24, 2015 at 01:39:42PM +0000, Daniel Helgenberger wrote:
>>> Hello,
>>>
>>> I recently experienced an issue with mac address uses in ovirt with
>>> foreman[1].
>>>
>>> Bottom line, a mac address was recycled causing an issue where I could not
>>> rebuild a host because of a stale DHCP reservation record.
>>>
>>> What is the current behavior regarding the reuse of MAC addresses for new
>>> VMs?
>>> Can I somehow delay a the recycle of a MAC?
>>
>> Martin, I recall we had a bug asking not to immediately re-use a
>> recently-released MAC address. Was this possible?
>>
> 

-- 
Daniel Helgenberger
m box bewegtbild GmbH

P: +49/30/2408781-22
F: +49/30/2408781-10

ACKERSTR. 19
D-10115 BERLIN


www.m-box.de  www.monkeymen.tv

Geschäftsführer: Martin Retschitzegger / Michaela Göllner
Handeslregister: Amtsgericht Charlottenburg / HRB 112767