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? Thanks! -- 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
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?
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 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?
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
----- 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.
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
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
participants (3)
-
Dan Kenigsberg -
Daniel Helgenberger -
Martin Mucha