Bug 1126920

Summary: [engine] MAC pool ranges option does not utilize full range of MACs
Product: [Retired] oVirt Reporter: Gadi Ickowicz <gickowic>
Component: ovirt-engine-coreAssignee: Lior Vernia <lvernia>
Status: CLOSED CURRENTRELEASE QA Contact: Pavel Stehlik <pstehlik>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 3.5CC: bazulay, cmestreg, ecohen, gcheresh, gklein, iheim, lvernia, mburman, nlevinki, rbalakri, yeylon
Target Milestone: ---Keywords: AutomationBlocker, Regression, Triaged
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: network
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-10-17 12:22:04 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Network RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 1127245    
Bug Blocks: 1073943    
Attachments:
Description Flags
engine logs none

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):
ovirt-engine-3.5.0-0.0.master.20140722232058.git8e1babc.el6.noarch

How reproducible:
100%

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.