[ovirt-users] MAC address recycling

[Daniel Helgenberger]

On 02.10.2015 07:54, Martin Mucha wrote:
> 
> 
> ----- Original Message -----
>>
>>
>> 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?
> 
> Yes, please. I'm currently on PTO, and this has to be planned anyways (and that's not done by me). Please specify there as well whether depicted solution I wrote about in last mail would be fine to you, or whether you actually need some delaying. I believe new methods for replacing should be ideal solution, but I don't know all your constraints and I did not look sufficiently thoroughly into code to be sure how easy/problematic it is. 
> 
FYI:
https://bugzilla.redhat.com/show_bug.cgi?id=1269301

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

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