Bug 1126920 - [engine] MAC pool ranges option does not utilize full range of MACs
Summary: [engine] MAC pool ranges option does not utilize full range of MACs
Alias: None
Product: oVirt
Classification: Retired
Component: ovirt-engine-core
Version: 3.5
Hardware: Unspecified
OS: Unspecified
Target Milestone: ---
: 3.5.0
Assignee: Lior Vernia
QA Contact: Pavel Stehlik
Whiteboard: network
Depends On: 1127245
Blocks: 1073943
TreeView+ depends on / blocked
Reported: 2014-08-05 15:19 UTC by Gadi Ickowicz
Modified: 2016-02-10 19:36 UTC (History)
11 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2014-10-17 12:22:04 UTC
oVirt Team: Network

Attachments (Terms of Use)
engine logs (324.59 KB, application/gzip)
2014-08-05 15:19 UTC, Gadi Ickowicz
no flags Details

System ID Private Priority Status Summary Last Updated
oVirt gerrit 31316 0 None None None Never

Description Gadi Ickowicz 2014-08-05 15:19:59 UTC
Created attachment 924243 [details]
engine logs

Description of problem:
Setting a range of MACs for use by using engine-config -s MacPoolRanges does not allow full range to be utilized. 

For example, setting the following range:
[root@gadi-rhevm ~]# engine-config -g MacPoolRanges
MacPoolRanges: 00:1a:4a:c0:69:00-00:1a:4a:c0:69:01 version: general

Should allow 2 NICs to be created with auto-assigned MACs, yet only one can be created. 

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Set MAC Pool Range to a known range using engine-config (and restart ovirt-engine service)
2. Attempt to add number of nics equal to range size

Actual results:
Fails to add the last NIC (range is actually 1 less than expected)

Expected results:
Should allow full range to be utilized, or documented that one of the edges of the range is not inclusive

Additional info:

Comment 1 Lior Vernia 2014-08-10 11:14:11 UTC
Gil, why is this marked as a blocker for the 3.5 release? Is it simply because it's blocking automation?

Otherwise, on a typical deployment there won't be 2 MAC addresses, there will be 10,000 out of which one won't be useable. So doesn't sound like a blocker to me.

Comment 2 Gil Klein 2014-08-10 11:29:33 UTC
Yes, automation blocker is the main reason to block it. 

I agree this is not a typical deployment use case, but currently we lost our visibility on some QE jobs.

Comment 3 Lior Vernia 2014-08-11 15:01:55 UTC
In the future, it might be a good idea to make test jobs less fragile. While it is a bug that one MAC address out of a range isn't usable, it should be moderately minor. I don't see a reason why critical automatic tests would depend on 100% utilization of a freakishly small MAC range in order to run.

Comment 5 Michael Burman 2014-09-09 10:43:29 UTC
Verified on - 3.5.0-0.10.master.el6ev

Comment 6 Sandro Bonazzola 2014-10-17 12:22:04 UTC
oVirt 3.5 has been released and should include the fix for this issue.

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