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.
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?
(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.
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
(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.
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 ***