Description of problem: Trying to import VM as clone, when the same origin VM name already exist in DC but the imported VM name has been renamed, is rejected by Webadmin with the next pop-up error: centos44%/\&+=?!@#$^*()[]: Import VM failed - VM Name already exist in the Data Center. Please rename the VM in the Data Center first and the next engine.log: 2018-01-04 15:11:25,524+02 WARN [org.ovirt.engine.core.bll.exportimport.ImportVmFromExternalProviderCommand] (default task-18) [] Validation of action 'ImportVmFromExternalProvider' failed for user admin@internal-authz. Reasons: VAR__ACTION__IMPORT,VAR__TYPE__VM,VM_CANNOT_IMPORT_VM_NAME_EXISTS Version-Release number of selected component (if applicable): rhvm-4.2.0.2-0.1.el7.noarch qemu-kvm-rhev-2.9.0-16.el7_4.13.x86_64 sanlock-3.5.0-1.el7.x86_64 libvirt-client-3.2.0-14.el7_4.5.x86_64 vdsm-4.20.9.3-1.el7ev.x86_64 virt-v2v-1.36.3-6.el7_4.3.x86_64 How reproducible: 100% Steps to Reproduce: 1. Browse Webadmin -> compute -> VMs -> more button -> import dialog 2. Enter external provider details, click "load" button and select VM which already exist in DC. 3. Verify clone is checked, rename VM name and click ok button Actual results: Action failed Expected results: Import should not be rejected when importing VM as clone and renaming it if there's the same origin VM name in the DC Additional info: Issue is also relevant for OVA import. engine.log and screenshot attached
Created attachment 1376945 [details] engine.log look at 2018-01-04 15:11:25,524+02
Created attachment 1376946 [details] Webamdin import dialog
is it the same issue with changes not applied?
(In reply to Michal Skrivanek from comment #3) > is it the same issue with changes not applied? Yes, it is the same issue as in bug 1529248.
Verification builds: rhvm-4.2.2.4-0.1.el7 vdsm-4.20.22-1.el7ev.x86_64 virt-v2v-1.36.10-6.el7.x86_64 libvirt-client-3.9.0-14.el7.x86_64 Verification scenario: 1. Import VMs as clone from VMware, Xen and KVM environments 2. Import VMware OVA and RHV OVA as clone 3. Verify VMs imported successfully. 4. Run VMs and verify VMs are running.
This bugzilla is included in oVirt 4.2.2 release, published on March 28th 2018. Since the problem described in this bug report should be resolved in oVirt 4.2.2 release, it has been closed with a resolution of CURRENT RELEASE. If the solution does not work for you, please open a new bug report.