Red Hat Bugzilla – Bug 1494916
[4.1.7 clone] Engine assigning MAC addresses which are in use by VMs when creating new VM from template
Last modified: 2017-11-07 12:27:54 EST
+++ This bug was initially created as a clone of Bug #1491132 +++ Description of problem: Engine assigning MAC addresses which are in use by VMs when creating new VM from template. If creating new VM based on template, engine assigning MAC addresses which are already in use by some VMs in the destination cluster when are no duplicate is allowed! Version-Release number of selected component (if applicable): 4.2.0-0.0.master.20170912134930.gitc81ca84.el7.centos How reproducible: Seems to be 100% Steps to Reproduce: 1. Create few VMs with few vNICs on each - no duplicate allowed in cluster! 2. Create template from one of the VMs 3. Create new VM based on the template Actual results: Engine assigned some of the vNIC with MAC addresses that are in use by VMs in the cluster. Expected results: Engine should not assign MAC addresses which are in use and no duplicate is allowed in the cluster. --- Additional comment from Michael Burman on 2017-09-13 03:29 EDT --- --- Additional comment from Red Hat Bugzilla Rules Engine on 2017-09-13 03:49:51 EDT --- This bug report has Keywords: Regression or TestBlocker. Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP. --- Additional comment from Meni Yakove on 2017-09-14 03:44:47 EDT --- Also when creating a new VM (not from a template) add vNIC failed with MAC already in use. --- Additional comment from Martin Mucha on 2017-09-14 05:08:09 EDT --- Thanks for finding this, code relied on vm interfaces being set after VM being obtained from DB, which is not happening. In such case, extra DB call has to be made to fetch VM nics. I overlook that and unit tests did not reveal this, because read from DB is mocked. Sorry about that. --- Additional comment from Martin Mucha on 2017-09-14 05:12:14 EDT --- (In reply to Martin Mucha from comment #4) > Thanks for finding this, code relied on vm interfaces being set after VM > being obtained from DB, which is not happening. In such case, extra DB > call has to be made to fetch VM nics. I overlook that and unit tests did not > reveal this, because read from DB is mocked. Sorry about that. so to put it more clearly, this error means, that *no* macs are discovered and registered on startup, every used mac is thus considered as unused. Patch has already +2, so it will be merged very soon. --- Additional comment from Michael Burman on 2017-09-18 03:13:12 EDT --- Verified on - 4.2.0-0.0.master.20170917124606.gita804ef7.el7.centos
Meni, why did you clone this bug? Does it happen again? Or is it here so we don't forget to merge it to ovirt-4.1.7?
We saw this on 4.1.7 in our automation tests
ovirt-engine-4.1.7.1-0.1.el7.noarch
there are several patches still pending https://gerrit.ovirt.org/#/q/status:open+project:ovirt-engine+branch:ovirt-engine-4.1+topic:backported-removeAddForceMac
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.1.z': '?'}', ] For more info please contact: rhv-devops@redhat.comINFO: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found non-acked flags: '{'rhevm-4.1.z': '?'}', ] For more info please contact: rhv-devops@redhat.com
Time to test this in 4.1.z, too.
Verified on - 4.1.7.2-0.1.el7
No need to document this temporary regression, which has never reached any customer.
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, 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/RHEA-2017:3138