+++ This bug is an upstream to downstream clone. The original bug is: +++ +++ bug 1525353 +++ ====================================================================== 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. (Originally by Michael Burman)
The bug is the d/s build as well 4.2.0.2-0.1.el7 (Originally by Michael Burman)
Created attachment 1367104 [details] record1 (Originally by Michael Burman)
Created attachment 1367105 [details] engine log (Originally by Michael Burman)
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. (Originally by rule-engine)
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). (Originally by Michael Burman)
(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))) (Originally by Michael Burman)
Postponing to 4.2.1, as this does not seem to affect the Ansible-driver disaster-recovery flow. (Originally by danken)
What about a fix for 4.1? this bug should be cloned to 4.1 as it exist in 4.1 for VMs flow. (Originally by Michael Burman)
Yaniv Lavi wants this in (Originally by danken)
WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ] For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason: [Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ] For more info please contact: rhv-devops
(In reply to RHV Bugzilla Automation and Verification Bot from comment #11) > WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following > reason: > > [Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ] > > For more info please contact: rhv-devops: Bug status wasn't > changed from MODIFIED to ON_QA due to the following reason: > > [Found clone flags: ['rhevm-4.1.z', 'rhevm-4.2-ga'], ] > > For more info please contact: rhv-devops this is already a clone, fixed the flags and moved to qe
Verified on - 4.1.10-0.1.el7
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/RHBA-2018:0562
BZ<2>Jira Resync