Bug 1295867

Summary:	[RFE] v2v: Warn when imported VM MAC address is not within oVirt DC MAC address pool range.
Product:	[oVirt] ovirt-engine	Reporter:	Nisim Simsolo <nsimsolo>
Component:	RFEs	Assignee:	Michal Skrivanek <michal.skrivanek>
Status:	CLOSED DUPLICATE	QA Contact:	Gil Klein <gklein>
Severity:	medium	Docs Contact:
Priority:	medium
Version:	---	CC:	bugs, gklein, lsurette, mgoldboi, nsimsolo, rbalakri, yeylon, ykaul
Target Milestone:	ovirt-4.0.0-alpha	Flags:	mgoldboi: ovirt-3.6.z? mgoldboi: ovirt-4.0.0? mgoldboi: planning_ack+ rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2016-04-04 06:42:09 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	Virt	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:	1209795, 1226206, 1362589
Bug Blocks:

Description Nisim Simsolo 2016-01-05 16:09:16 UTC

Description of problem:
Currently, when importing VM from VMware, VM MAC address is copied from source, without the option to change destination MAC address before the import.
This may lead to out of the range MAC address and it is also possible that imported VM will not get IP from DHCP server.
Also, it can lead to layer 2 duplication if the user is running source VM and imported VM at the same time.

Version-Release number of selected component (if applicable):
rhevm-3.6.2-0.1.el6
libvirt-client-1.2.17-13.el7_2.2.x86_64
qemu-kvm-rhev-2.3.0-31.el7_2.4.x86_64
vdsm-4.17.15-0.el7ev
sanlock-3.2.4-1.el7.x86_64

How reproducible:
Consistently.

Steps to Reproduce:
1. Import VM from VMware environment.
2.
3.

Actual results:
MAC address copied from source VM to imported VM.

Expected results:
Behavior should be aligned with import from export domain behavior:
Generate new MAC, if MAC is not within the defined range. Otherwise, use it unless DC 'allow duplicates' value is false and MAC address is already assigned.

Additional info:
bug severity set to medium because it is possible to change the MAC address manually after the import.

Comment 1 Yaniv Kaul 2016-01-06 06:32:13 UTC

I'm honestly not sure I'd like that. The MAC is recorded in multiple places within the VM (for example, Windows activation relies on it, or in Linux in /etc/sysconfig/network-scripts/ifcfg-* files). It'll cause mess in the network configuration. 

Yaniv D. - thoughts?

Comment 2 Yaniv Lavi 2016-01-06 13:38:12 UTC

(In reply to Yaniv Kaul from comment #1)
> I'm honestly not sure I'd like that. The MAC is recorded in multiple places
> within the VM (for example, Windows activation relies on it, or in Linux in
> /etc/sysconfig/network-scripts/ifcfg-* files). It'll cause mess in the
> network configuration. 
> 
> Yaniv D. - thoughts?

We should consider doing a soft enforcement as default since there is now several times we hit this issue. See suggested RFE #1209795 from customer to highlight a VM based on this.

Comment 3 Michal Skrivanek 2016-02-22 12:47:01 UTC

if we do bug 1209795 we don't imho need any extra action for v2v. It is kind of expected that you want to do further changes once v2v finishes, eg. for stuff specific to oVirt not present in original environment

I'm proposing to close this as addressed by bug 1209795

Comment 4 Moran Goldboim 2016-04-03 12:40:34 UTC

(In reply to Michal Skrivanek from comment #3)
> if we do bug 1209795 we don't imho need any extra action for v2v. It is kind
> of expected that you want to do further changes once v2v finishes, eg. for
> stuff specific to oVirt not present in original environment
> 
> I'm proposing to close this as addressed by bug 1209795

keeping this one open for verification reasons for this use case.
bug 1209795 should indeed take care of this use case.

Comment 5 Michal Skrivanek 2016-04-04 06:42:09 UTC

I think it's best to copy the case to the dependent bug. I don't see a reason to leave this one around, without any action

*** This bug has been marked as a duplicate of bug 1209795 ***