Created attachment 924243 [details]
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):
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
Fails to add the last NIC (range is actually 1 less than expected)
Should allow full range to be utilized, or documented that one of the edges of the range is not inclusive
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.
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.
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.
Verified on - 3.5.0-0.10.master.el6ev
oVirt 3.5 has been released and should include the fix for this issue.