Description of problem: vNIC mapping is broken on import from data domain - vNICs mapped as 'Empty' in the destination cluster. We have a new regression for the vNIC mappings from data domain. It seems that the vNIC are mapped as 'Empty' on the destination target. Version-Release number of selected component (if applicable): 4.2.1-0.0.master.20171211205712.git7b1f4d1.el7.centos - It is 100% reproducible if you press the 'vNIC Profiles Mapping'(and close it without a change) button prior approving the import operation. Steps to Reproduce: 1. Import VM/Template from data domain with some vNICs and different profiles without re-assigning new or different profiles for the destination cluster. Before approving press on the 'vNIC Profiles Mapping' button and close it and then Just import as it is. Actual results: All vNICs are mapped as 'Empty' in the destination cluster. Expected results: Must work as expected.
The bug is the d/s build as well 4.2.0.2-0.1.el7
Created attachment 1367104 [details] record1
Created attachment 1367105 [details] engine log
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.
Note for my self and dev - - Another vise-versa flow is: import vm or template with 3 vNICs, all mapped as 'Empty' in the origin prior import. Remap only 1 nic on target to some profile9ovirtmgmt) and keep other 2 nics as empty. After import all 3 nics will imported with the first nic's profile(ovirtmgmt).
(In reply to Michael Burman from comment #5) > Note for my self and dev - > > - Another vise-versa flow is: > import vm or template with 3 vNICs, all mapped as 'Empty' in the origin > prior import. Remap only 1 nic on target to some profile9ovirtmgmt) and keep > other 2 nics as empty. > After import all 3 nics will imported with the first nic's > profile(ovirtmgmt). Note for my self and dev, please ignore this flow and comment as it's expected)))
Postponing to 4.2.1, as this does not seem to affect the Ansible-driver disaster-recovery flow.
What about a fix for 4.1? this bug should be cloned to 4.1 as it exist in 4.1 for VMs flow.
Yaniv Lavi wants this in
The bug not in the latest d/s build or wasn't properly fixed. Any how it failedQa on 4.2.1-0.2.el7 The fix should have been in this build.
Created attachment 1378056 [details] engine failedQA
Created attachment 1379378 [details] expected behavior in various scenarios affected by this bug as agreed by dev+qe
Can't test the template flow and VMs flow properly as i'm blocked with new bug - BZ 1536966
Verified on - 4.2.1.3-0.1.el7
This bugzilla is included in oVirt 4.2.1 release, published on Feb 12th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.1 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.