Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1613029

Summary: [docs][v2v] RHV should be configured to allow MAC addresses of virt-v2v migrated VMs
Product: [oVirt] ovirt-engine Reporter: Mor <mkalfon>
Component: DocumentationAssignee: Avital Pinnick <apinnick>
Status: CLOSED CURRENTRELEASE QA Contact: Ilanit Stein <istein>
Severity: low Docs Contact:
Priority: unspecified    
Version: futureCC: adahms, apinnick, bugs, dagur, dfediuck, michal.skrivanek, rbarry, royoung
Target Milestone: ovirt-4.3.3Keywords: Documentation
Target Release: ---Flags: rule-engine: ovirt-4.3+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-05-02 09:13:20 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:
Attachments:
Description Flags
logs and screenshot none

Description Mor 2018-08-06 19:31:03 UTC
Created attachment 1473727 [details]
logs and screenshot

Description of problem:
As per our email conversation: virt-v2v copies the source VM vNIC MAC address on the destination VM to prevent issues with software that relies on MAC address as an ID. To support this requirement RHV should be configured by the user to allow MAC addresses of migrated VMs using MAC pool range(s), otherwise virt-v2v tool will fail with the following error message:

v2v-import-20180806T084556-42111.log:ovirtsdk4.Error: Fault reason is "Operation Failed". Fault detail is "[Cannot import Virtual Machine, because that action would create duplicates in target MAC pool, which are not allowed. Either allow duplicate MACs in MAC Pool, or allow reassignment of bad MACs during import. Problematic NICs are  VmNetworkInterface:{id='cb317d58-da13-41ac-ba04-e2345d6656de', name='eth0', networkName='ovirtmgmt', vnicProfileName='null', vnicProfileId='null', speed='10000', type='3', macAddress='00:50:56:a4:9d:9a', active='true', linked='true', portMirroring='false', vmId='f0f2f50a-fb09-4973-a4e6-06de096cab9d', vmName='null', vmTemplateId='null', QoSName='null', remoteNetworkName='ovirtmgmt'}]". HTTP response code is 409.
resulting in CFME migration plan failure.

And RHV will fail with the following event on the VM:
<VM_NAME> has MAC address(es) <MAC_ADDRESS>, which is/are out of its MAC pool definitions.

Version-Release number of selected component (if applicable):
RHV 4.2.5.2-0.1.el7ev
CFME 5.9.4.2.20180802030318_f91df08

How reproducible:
100%

Steps to Reproduce:
1. Run a migration plan on CFME to migrate a VM with MAC address not in the configured MAC pool of the target cluster on RHV.

Actual results:
Error message - see above.

Expected results:
Documentation for manual steps or automation in engine should be added.

Additional info:
Similar bug opened last year:
https://bugzilla.redhat.com/show_bug.cgi?id=1467846#c4

Comment 1 Mor 2018-08-06 19:35:22 UTC
*** Bug 1612883 has been marked as a duplicate of this bug. ***

Comment 5 Michal Skrivanek 2018-08-07 06:45:23 UTC
I think it should elaborate on the different results you get with different mac pool settings.
By default you do not need to touch anything, but the imported VMs will use MACs from outside of the pool. This might be surprising since any newly created VM will use MAC from the pool so they'll have entirely different MAC prefixes.
OTOH If you choose to configure a MAC Pool range matching the VMware range then the conversion will fail if there is already a VM in the destination DC with the same MAC. Unless "allow duplicate MACs" is enabled for this MAC Pool.

Comment 9 Mor 2018-08-07 09:07:47 UTC
I wasn't able to reproduce it on another VM migration not using CSV as input method for VM names. changing severity to low.

Comment 10 Sandro Bonazzola 2019-01-28 09:36:30 UTC
This bug has not been marked as blocker for oVirt 4.3.0.
Since we are releasing it tomorrow, January 29th, this bug has been re-targeted to 4.3.1.

Comment 11 Sandro Bonazzola 2019-03-22 10:44:49 UTC
4.3.1 has been released a while ago, re-targeting to 4.3.3 for re-evaluation.

Comment 12 Michal Skrivanek 2019-04-15 12:28:54 UTC
this is a documentation bug actually

Comment 13 Daniel Gur 2019-04-23 07:43:40 UTC
Hi Avital, Did you already documented the above?
If yes please send us a link and move this bug to on-qa so we could verify

Comment 16 Ilanit Stein 2019-04-30 12:17:33 UTC
Michal,

I've been testing v2v imports since RHV-4.2.8-4/CFME-5.10.0.32,
and I never added the source mac address to the RHV mac pool range,
however the imports worked fine.

I wonder - Is this doc bug still relevant?
Maybe the code behavior had changed, 
so that it no longer fails the import, if the source mac is not included in RHV mac pool?

Thanks.

Comment 17 Ryan Barry 2019-04-30 12:39:54 UTC
Still relevant. comment#5 is very clear

"If VMs are imported, and a MAC pool for that range has been created for RHV, the import may fail if an existing VM already has claimed that MAC"

"If VMs are imported, and a MAC pool for that range has not been created, no steps are necessary, but additional interfaces created o that VM (and VMs created without importing) will not have MAC addresses in the same range"

It's a question of desired behavior from the end user

Comment 18 Michal Skrivanek 2019-04-30 13:28:28 UTC
(In reply to Avital Pinnick from comment #15)

Avital, for the step 6 you added, I would also mention that it's not mandatory. You may wish to configure a new pool matching the VMware range, or not. You will get a different behavior, but you may freely choose one or the other.
We should perhaps say "Optional: " and describe briefly (as in comment #17, thanks Ryan!) the difference

Thanks,
michal

Comment 20 Michal Skrivanek 2019-05-01 13:40:06 UTC
LGTM