Description of problem: After Detaching and attaching a storage domain to a different DC (or even the same DC), import vm fails due to MAC duplication with the error: MAC Address is already in use: <MAC Address> Version-Release number of selected component (if applicable): ovirt-engine-4.1.0-0.0.master.20161116231317.git10b5ca9.el7.centos.noarch How reproducible: 100% Steps to Reproduce: 1. create vm on random storage domain (with disks and nic attached). 2. move the sd to maintenance mode and detach it from the dc. 3. attach the sd to a different dc or re-attach it to the same one. 4. in storage tab > select attached sd > VM import > import the vm you've created in the first step Actual results: Import is failing with 'MAC Address is already in use' Expected results: VM is imported from the sd to the environment with no errors. Additional info: This case was tested both on block-based storage and nfs storage, from shared dc to local dc and vice-versa and from shared to shared dc. In all cases import failed. Also, when I removed the nic from the vm before detaching the storage domain, the import was successful. engine.log 2016-11-29 13:15:18,326 WARN [org.ovirt.engine.core.bll.exportimport.ImportVmFromConfigurationCommand] (default task-10) [072276c8-c1ee-4c3f-a13e-f066a0feba9c] Validation of action 'ImportVmFromConfiguration' failed for user admin@internal-authz. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,NETWORK_MAC_ADDRESS_IN_USE_DETAILED,$NETWORK_MAC_ADDRESS_IN_USE_DETAILED_LIST 00:1a:4a:16:01:54,$NETWORK_MAC_ADDRESS_IN_USE_DETAILED_LIST_COUNTER 1
Created attachment 1226171 [details] engine.log
(In reply to Lilach Zitnitski from comment #0) > After Detaching and attaching a storage domain to a different DC (or even > the same DC), import vm fails due to MAC duplication with the error: > MAC Address is already in use: <MAC Address> Moving to the Network team for investigation. I know they's been doing some work on this area recently, but I can't tell if this work caused this problem (by mistake), or if it's a gap they haven't got to yet.
*** This bug has been marked as a duplicate of bug 1226206 ***
*** This bug has been marked as a duplicate of bug 1317447 ***