Bug 1414856 - Engine re-assign MAC addresses without requesting to re-assign them on VM import
Summary: Engine re-assign MAC addresses without requesting to re-assign them on VM import
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: BLL.Network
Version: 4.1.0
Hardware: x86_64
OS: Linux
medium
high
Target Milestone: ovirt-4.1.0-rc
: 4.1.0.3
Assignee: Yevgeny Zaspitsky
QA Contact: Michael Burman
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-01-19 15:30 UTC by Michael Burman
Modified: 2017-02-01 14:56 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-02-01 14:56:50 UTC
oVirt Team: Network
Embargoed:
rule-engine: ovirt-4.1+

Attachments (Terms of Use)
engine log (431.10 KB, application/x-gzip)
2017-01-19 15:30 UTC, Michael Burman 		no flags Details
View All


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 70885 0 master MERGED engine: re-assign MAC when it's explicitly requested only 2017-01-21 07:34:05 UTC
oVirt gerrit 70886 0 ovirt-engine-4.1 MERGED engine: re-assign MAC when it's explicitly requested only 2017-01-22 09:13:34 UTC

Description Michael Burman 2017-01-19 15:30:17 UTC 
Created attachment 1242514 [details]
engine log

Description of problem:
Engine re-assign MAC addresses without requesting to re-assign them on VM import from data domain.

When importing VM with MAC address that is out of range and we don't request to re-assign it, the VM get new MAC from the destination pool.
In the event ui log it reports - 
'  VM NEW2 has MAC address(es) 00:00:00:00:00:21, which is/are out of its MAC pool definitions'
But get new MAC instead. 

Version-Release number of selected component (if applicable):
4.1.0.1-0.4.master.20170118134729.gitf34da1f.el7.centos

How reproducible:
100

Steps to Reproduce:
1. Import VM from data domain with MAC address that is out of the range and don't request to re-assign it.


Actual results:
vNIC got new MAC

Expected results:
vNIC should remain with the original MAC address.
Comment 1 Red Hat Bugzilla Rules Engine 2017-01-19 18:18:33 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 2 Sandro Bonazzola 2017-01-23 14:27:30 UTC 
Danken, this is marked as blocker for 4.1.0 after we released 4.1.0 RC, been in 4.1.1 target in the past 4 days.
Has this issue any workaround? Otherwise we need to plan a 4.1.0 respin and probably postpone GA.
Comment 3 Yaniv Kaul 2017-01-23 14:29:13 UTC 
If it missed the rebuild, then it should go to 4.1.1.
Comment 4 Dan Kenigsberg 2017-01-23 16:25:12 UTC 
This is NOT an RC blocker, and it should not postpone GA. But I would like it to be included in the 4.1.0 d/s beta build scheduled for next week.
Comment 5 Michael Burman 2017-01-31 08:30:15 UTC 
Verified on - 4.1.0.3-0.1.el7
Note You need to log in before you can comment on or make changes to this bug.