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 _______________________________________________ Users mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/users
