Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1491132

Summary: Engine assigning MAC addresses which are in use by VMs when creating new VM from template
Product: [oVirt] ovirt-engine Reporter: Michael Burman <mburman>
Component: BLL.NetworkAssignee: Martin Mucha <mmucha>
Status: CLOSED CURRENTRELEASE QA Contact: Michael Burman <mburman>
Severity: urgent Docs Contact:
Priority: high    
Version: 4.2.0CC: bugs, myakove
Target Milestone: ovirt-4.2.0Keywords: Regression
Target Release: ---Flags: rule-engine: ovirt-4.2+
rule-engine: blocker+
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Cause: wrong assumption during refactoring mac pools. During engine startup were incorrectly queried VmNics. Consequence: no macs were registered in mac pool at startup, master branch contained this error for about 5 days tops, it shouldn't cause any serious issues. Fix: During engine startup are VmNics queried correctly now. Result: VmNics are queried and registered in mac pool correctly now.
 Story Points: ---
Clone Of:
: 1494916 (view as bug list) Environment:
Last Closed: 2017-12-20 11:30:44 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:    
Bug Blocks: 1494916    
Attachments:
Description Flags
engine log none

Description Michael Burman 2017-09-13 07:28:48 UTC 
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.
Comment 1 Michael Burman 2017-09-13 07:29:27 UTC 
Created attachment 1325250 [details]
engine log
Comment 2 Red Hat Bugzilla Rules Engine 2017-09-13 07:49:51 UTC 
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.
Comment 3 Meni Yakove 2017-09-14 07:44:47 UTC 
Also when creating a new VM (not from a template) add vNIC failed with MAC already in use.
Comment 4 Martin Mucha 2017-09-14 09:08:09 UTC 
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.
Comment 5 Martin Mucha 2017-09-14 09:12:14 UTC 
(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.
Comment 6 Michael Burman 2017-09-18 07:13:12 UTC 
Verified on - 4.2.0-0.0.master.20170917124606.gita804ef7.el7.centos
Comment 7 Sandro Bonazzola 2017-12-20 11:30:44 UTC 
This bugzilla is included in oVirt 4.2.0 release, published on Dec 20th 2017.

Since the problem described in this bug report should be
resolved in oVirt 4.2.0 release, published on Dec 20th 2017, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.