+++ This bug was initially created as a clone of Bug #1063064 +++ Description of problem: When trying to initialize a large range, for example 00:1A:4A:01:00:00-00:1A:4A:FF:FF:FF, with a large MaxMacsCountInPool value, an OOM error would occur. Version-Release number of selected component (if applicable): How reproducible: 100% Steps to Reproduce: 1. engine-config -s MaxMacsCountInPool=16777216 2. engine-config -s MacPoolRanges=00:1A:4A:01:00:00-00:1A:4A:FF:FF:FF 3. start the engine Actual results: You will see in the log something similar to 2014-02-09 19:57:44,368 INFO [org.ovirt.engine.core.bll.network.MacPoolManager] (org.ovirt.thread.pool-4-thread-1) MacPoolManager(4dccea71): Start initializing Later the initialization would fail (no log for this though) and you would start seeing OutOfMemoryError popping up during the application run. Expected results: The MacPoolManager should finish initializing (shouldn't take very long). Additional info: The internal implementation of MacPoolManager should be changed to something more CU & memory efficient that a set containing all unallocated MACs.
Verified on - oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6
Hi Martin, Could you provide doc text for this bug for release notes ASAP. Cheers, Julie
Hi Martin, Could you check the doc text again and let me know if this is correct? Kind regards, Julie
Martin, please respond to Julie's request. Julie, there's also some behavior change in MAC address range configuration following this feature - should this be described as part of the release notes? If so, please use Martin's aid in describing the change (Martin - I'm referring to the new leniency with trimmed addresses, unless the resulting range is completely empty).
Adding as Julie is on leave...
Hi Lior, Thank you for raising the needinfo request! As far as this release note is concerned, as long as the doc text captures the issue that was raised and how it was resolved for this bug, that is great. I am a little curious about the change in behavior, though. Is this an entirely back-end change, or does it affect the way in which users would configure anything? What is the general impact on users? Kind regards, Andrew
Hi Andrew, the change is user-facing. If I'm not mistaken (Martin, feel free to correct me): * Previously if a provided MAC address range contained any invalid MAC addresses (e.g. multicast), the engine-config operation would fail altogether. * In 3.5, invalid addresses are filtered out of the ranges and the operation succeeds; that is, unless after filtering invalid addresses you are left with none, in which case the operation fails.
Hi Lior, Thank you for the additional information. One more question from my end - was the change you described implemented in this bug? Or, was it implemented in a separate bug? Kind regards, Andrew
Like lior said, previously if any range contained multicast value set through the engine-config was rejected. Now there is some effort made to correct user input if possible. Some changes were made here, but there's also a bug fixed here: https://bugzilla.redhat.com/show_bug.cgi?id=1165025
Hi Andrew, No problem. Yes, it was part of this feature's implementation. And we've just recalled another user-facing behavior change related to this feature: the MaxMacsCountInPool configuration value was deprecated, and only the MacPoolRanges configuration value is considered when allocating MAC addresses. I apologize for being late with this - we didn't remember this specific patch was already merged in time for 3.5. So - these two behavior changes belong in the release notes or somewhere else? Lior.
Hi Martin, Lior, I think the best way to document these changes would be as release notes in the bugs where the main changes were made. For example, BZ#1165025 for the validation work. I will check on the current status of the release notes, see if there is something we can do there, and get back to you. Kind regards, Andrew
Andrew, please note that the first behavior change existed before Bug 1165025 was fixed. It was just a little different than what I described (the failure in the case of empty ranges after filtering was less elegant). Bug 1165025 didn't exist in 3.4 - it was only opened due to this feature being implemented, so there's no point in documenting anything on it (it never existed in a customer-facing release). So I think all discussed documentation is related to this RFE - just not sure it should be part of the release notes.
Hi Lior, Understood - thank you for the clarification. I think the release notes would be the right place to document this. Once again, I will check whether we can make changes at this time, and will provide an update. Kind regards, Andrew
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0158.html