|Summary:||Engine re-assign MAC addresses without requesting to re-assign them on VM import|
|Product:||[oVirt] ovirt-engine||Reporter:||Michael Burman <mburman>|
|Component:||BLL.Network||Assignee:||Yevgeny Zaspitsky <yzaspits>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Michael Burman <mburman>|
|Version:||4.1.0||CC:||bugs, danken, eedri, ykaul|
|Fixed In Version:||Doc Type:||If docs needed, set a value|
|Doc Text:||Story Points:||---|
|Last Closed:||2017-02-01 14:56:50 UTC||Type:||Bug|
|oVirt Team:||Network||RHEL 7.3 requirements from Atomic Host:|
|Cloudforms Team:||---||Target Upstream Version:|
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): 22.214.171.124-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 - 126.96.36.199-0.1.el7