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