Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1077284 - [RFE] Allow big ranges in MacPoolManager
Summary: [RFE] Allow big ranges in MacPoolManager
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: RFEs
Version: 3.3.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 3.5.0
Assignee: Martin Mucha
QA Contact: Martin Pavlik
URL:
Whiteboard: network
Depends On: 1063064
Blocks: rhev3.5beta 1156165
TreeView+ depends on / blocked
 
Reported: 2014-03-17 16:06 UTC by Nir Yechiel
Modified: 2016-02-10 19:47 UTC (History)
16 users (show)

Fixed In Version:
Doc Type: Release Note
Doc Text:
With this feature, users can now configure a MAC pool with larger address ranges. Red Hat recommends to configure the MAC address pool to contain the majority of MAC addresses to be used. Only MAC addresses defined in the MAC address pool will be stored in memory efficiently.
Clone Of: 1063064
Environment:
Last Closed: 2015-02-11 17:59:16 UTC
oVirt Team: Network
Target Upstream Version:
nyechiel: Triaged+


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2015:0158 normal SHIPPED_LIVE Important: Red Hat Enterprise Virtualization Manager 3.5.0 2015-02-11 22:38:50 UTC

Description Nir Yechiel 2014-03-17 16:06:51 UTC
+++ 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.

Comment 1 Michael Burman 2014-08-25 08:21:37 UTC
Verified on -  oVirt Engine Version: 3.5.0-0.0.master.20140821064931.gitb794d66.el6

Comment 2 Julie 2014-12-01 06:45:57 UTC
Hi Martin, 
  Could you provide doc text for this bug for release notes ASAP. 

Cheers,
Julie

Comment 3 Julie 2014-12-03 01:08:18 UTC
Hi Martin,
    Could you check the doc text again and let me know if this is correct?

Kind regards,
Julie

Comment 4 Lior Vernia 2014-12-15 14:02:44 UTC
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).

Comment 5 Lior Vernia 2014-12-15 14:51:19 UTC
Adding as Julie is on leave...

Comment 6 Andrew Dahms 2014-12-17 06:15:19 UTC
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

Comment 7 Lior Vernia 2014-12-17 06:36:53 UTC
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.

Comment 8 Andrew Dahms 2014-12-17 08:37:56 UTC
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

Comment 9 Martin Mucha 2014-12-17 08:52:36 UTC
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

Comment 10 Lior Vernia 2014-12-17 09:04:47 UTC
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.

Comment 11 Andrew Dahms 2014-12-17 09:09:02 UTC
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

Comment 12 Lior Vernia 2014-12-17 09:24:52 UTC
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.

Comment 13 Andrew Dahms 2014-12-17 12:29:10 UTC
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

Comment 20 errata-xmlrpc 2015-02-11 17:59:16 UTC
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


Note You need to log in before you can comment on or make changes to this bug.