Bug 1295867 - [RFE] v2v: Warn when imported VM MAC address is not within oVirt DC MAC address pool range.
[RFE] v2v: Warn when imported VM MAC address is not within oVirt DC MAC addre...
Status: CLOSED DUPLICATE of bug 1209795
Product: ovirt-engine
Classification: oVirt
Component: RFEs (Show other bugs)
---
Unspecified Unspecified
medium Severity medium (vote)
: ovirt-4.0.0-alpha
: ---
Assigned To: Michal Skrivanek
Gil Klein
:
Depends On: 1209795 1226206 1362589
Blocks:
  Show dependency treegraph
 
Reported: 2016-01-05 11:09 EST by Nisim Simsolo
Modified: 2016-08-23 05:50 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-04-04 02:42:09 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
mgoldboi: ovirt‑3.6.z?
mgoldboi: ovirt‑4.0.0?
mgoldboi: planning_ack+
rule-engine: devel_ack?
rule-engine: testing_ack?


Attachments (Terms of Use)

  None (edit)
Description Nisim Simsolo 2016-01-05 11:09:16 EST
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 01:32:13 EST
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 08:38:12 EST
(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 07:47:01 EST
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 08:40:34 EDT
(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 02:42:09 EDT
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 ***

Note You need to log in before you can comment on or make changes to this bug.