Bug 1593800 - [RFE] forbid new mac pools with overlapping ranges
Summary: [RFE] forbid new mac pools with overlapping ranges
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 4.1.8
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: ovirt-4.4.0
: 4.4.0
Assignee: eraviv
QA Contact: Michael Burman
URL:
Whiteboard: sync-to-jira
: 1492577 1537414 (view as bug list)
Depends On: 1639460
Blocks: 1537414 1767319
TreeView+ depends on / blocked
 
Reported: 2018-06-21 15:26 UTC by Igor Netkachev
Modified: 2020-08-04 13:16 UTC (History)
12 users (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
When creating a new MAC address pool, its ranges must not overlap with each other or with any ranges in existing MAC address pools.
Clone Of:
: 1639460 1767319 (view as bug list)
Environment:
Last Closed: 2020-08-04 13:16:11 UTC
oVirt Team: Network
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2020:3247 0 None None None 2020-08-04 13:16:36 UTC
oVirt gerrit 93689 0 'None' MERGED engine: block adding mac pool on range overlap 2021-02-05 06:17:12 UTC

Description Igor Netkachev 2018-06-21 15:26:55 UTC
Description of problem:

Customer uses Foreman oVirt compute resources to create VMs in RHV from Foreman.

When Foreman creates a new VM in RHV, the oVirt compute resource will first request a MAC address from RHV to assign to the VM. RHV selects this MAC address from a pool, defined per cluster. This is expected behaviour.

However, after a reboot, RHV will 'forget where it got to' in the pool, and start suggesting MAC addresses from the beginning of the pool again. These MAC addresses are likely to be in use by running VMs, so when the VM creation request is fired off from Foreman, RHV will refuse with the error:

Failed to create a compute xxxx (oVirt) instance xxxxx.com: MAC Address 00:1a:4a:xx:xx:xx is already in use.

Version-Release number of selected component (if applicable):
rhevm-4.1.8.2-0.1.el7.noarch

How reproducible:
100%

Steps to Reproduce:
1.Setup Foreman integration, setup MAC pool for RHV clustetr
2.Create VM with Foreman
3.Restart ovirt-engine
4.Create another VM  with Foreman, see error message 


Actual results:
"Failed to create a compute xxxx (oVirt) instance xxxxx.com: MAC Address 00:1a:4a:xx:xx:xx is already in use."

Expected results:
No error, RHV remembers last provided MAC and does not start from beginning of MAC pool range after engine restart

Comment 4 Dan Kenigsberg 2018-07-13 23:21:16 UTC
Igor, in "Upon reboot", do you mean "upon ovirt-engine restart"?
Would the customer upgrade to 4.2, or at least to the newest 4.1.z version? We have fixed macpool-related bugs in 4.1.11.

Eitan, could you look into the customer logs and database?

Comment 6 Igor Netkachev 2018-07-16 13:57:23 UTC
Dan,

In customer's scenario it was reboot of hosted-engine VM, but I believe this equates to engine restart.

I have asked customer to upgrade to at least 4.1.11 and re-test, will keep you updated on further progress.

Comment 8 Dan Kenigsberg 2018-07-22 13:12:55 UTC
In my opinion, we need to:
1. warn users if they have mac pools with overlapping ranges.
2. disallow creating new mac pools that overlap exiting ones.

Comment 9 eraviv 2018-07-24 09:02:34 UTC
In relation to part 2 in comment#7:
a. I tested the same situation on a 4.3-master engine and there is no crash. just and error message that duplicates exists in no-duplicate mac pool.
b. The crash I was referring to is for the scenario described in BZ1561080, BZ1554180 where if a mac pool constains duplicates, and a the mac pool is then marked with 'forbid duplicates' engine responds with dismay.

Comment 10 eraviv 2018-07-24 09:46:25 UTC
comment 9 continued: but trying to edit\delete mac pools or vnics on the VMs does prove to cause lots of trouble and mis-behavior, so I would like to re-emphasize the importance of resolving the issue before any upgrade. Igor, please ack.

Comment 11 Igor Netkachev 2018-07-24 15:00:32 UTC
Eitan,

Thank you very much for bringing my attention to RHV mis-behavior in case MAC overlap is not removed prior to upgrade! I have forwarded this information to the customer, will let you know once there's any feedback.

Comment 12 eraviv 2018-08-08 08:49:12 UTC
*** Bug 1537414 has been marked as a duplicate of this bug. ***

Comment 13 eraviv 2018-08-08 08:49:58 UTC
*** Bug 1492577 has been marked as a duplicate of this bug. ***

Comment 14 Dan Kenigsberg 2018-10-16 10:22:40 UTC
Warnings are going to be tracked in bug 1639460. Changes to the API behavior are postponed to 4.3.

Comment 15 Sandro Bonazzola 2019-01-28 09:40:12 UTC
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 18 eraviv 2019-10-31 07:40:21 UTC
this bug will now only track the RFE for creating new mac pools.
a clone - BZ#1767319 - has been created for the RFE for updating existing mac pools.

Comment 20 RHV bug bot 2019-12-13 13:15:46 UTC
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.com

Comment 21 RHV bug bot 2019-12-20 17:45:21 UTC
WARN: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (ON_QA) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.com

Comment 22 Michael Burman 2020-01-07 06:44:53 UTC
Verified on - rhvm-4.4.0-0.13.master.el7.noarch

Comment 23 RHV bug bot 2020-01-08 14:49:24 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.com

Comment 24 RHV bug bot 2020-01-08 15:17:01 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.com

Comment 25 RHV bug bot 2020-01-24 19:51:13 UTC
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.comINFO: Bug status (VERIFIED) wasn't changed but the folowing should be fixed:

[Found non-acked flags: '{}', ]

For more info please contact: rhv-devops@redhat.com

Comment 27 errata-xmlrpc 2020-08-04 13:16:11 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 (Important: RHV Manager (ovirt-engine) 4.4 security, bug fix, and enhancement update), 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://access.redhat.com/errata/RHSA-2020:3247


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