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
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?
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.
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.
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 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.
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.
*** Bug 1537414 has been marked as a duplicate of this bug. ***
*** Bug 1492577 has been marked as a duplicate of this bug. ***
Warnings are going to be tracked in bug 1639460. Changes to the API behavior are postponed to 4.3.
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.
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.
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: Bug status (ON_QA) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
Verified on - rhvm-4.4.0-0.13.master.el7.noarch
WARN: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops: Bug status (VERIFIED) wasn't changed but the folowing should be fixed: [Found non-acked flags: '{}', ] For more info please contact: rhv-devops
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