Bug 1530565

Summary:	[downstream clone - 4.1.10] vNIC mapping is broken on import from data domain - vNICs mapped as 'Empty' in the destination cluster
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	rhev-integ
Component:	ovirt-engine	Assignee:	eraviv
Status:	CLOSED ERRATA	QA Contact:	Michael Burman <mburman>
Severity:	urgent	Docs Contact:
Priority:	urgent
Version:	unspecified	CC:	apinnick, bugs, danken, eraviv, lsurette, mburman, rbalakri, Rhev-m-bugs, sbonazzo, srevivo, ykaul, ylavi
Target Milestone:	ovirt-4.1.10	Keywords:	Regression, ZStream
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:	Previously, when importing a virtual machine, if the vNIC profile mapping dialog was opened and canceled, the mapping was lost and the vNICs were not assigned a profile. In the current release, the default mapping that appears in the dialog is assigned to the vNICs when the import is complete.	Story Points:	---
Clone Of:	1525353	Environment:
Last Closed:	2018-03-20 16:37:08 UTC	Type:	---
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:	1525353
Bug Blocks:

Description rhev-integ 2018-01-03 11:13:29 UTC

+++ 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)

Comment 1 rhev-integ 2018-01-03 11:13:37 UTC

The bug is the d/s build as well 4.2.0.2-0.1.el7

(Originally by Michael Burman)

Comment 3 rhev-integ 2018-01-03 11:13:43 UTC

Created attachment 1367104 [details]
record1

(Originally by Michael Burman)

Comment 4 rhev-integ 2018-01-03 11:13:48 UTC

Created attachment 1367105 [details]
engine log

(Originally by Michael Burman)

Comment 5 rhev-integ 2018-01-03 11:13:53 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.

(Originally by rule-engine)

Comment 6 rhev-integ 2018-01-03 11:13:58 UTC

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)

Comment 7 rhev-integ 2018-01-03 11:14:02 UTC

(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)

Comment 8 rhev-integ 2018-01-03 11:14:07 UTC

Postponing to 4.2.1, as this does not seem to affect the Ansible-driver disaster-recovery flow.

(Originally by danken)

Comment 9 rhev-integ 2018-01-03 11:14:12 UTC

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)

Comment 10 rhev-integ 2018-01-03 11:14:16 UTC

Yaniv Lavi wants this in

(Originally by danken)

Comment 11 RHV bug bot 2018-02-14 21:16:15 UTC

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

Comment 12 Sandro Bonazzola 2018-02-15 09:47:13 UTC

(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

Comment 13 Michael Burman 2018-02-18 07:00:47 UTC

Verified on - 4.1.10-0.1.el7

Comment 20 errata-xmlrpc 2018-03-20 16:37:08 UTC

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

Comment 21 Franta Kust 2019-05-16 13:06:11 UTC

BZ<2>Jira Resync