Red Hat Bugzilla – Bug 1269948
Failed to import VM / VM Template
Last modified: 2016-03-10 06:59:37 EST
Description of problem: Failed to import VM. Version-Release number of selected component (if applicable): RHEVM: rhevm-lib-3.6.0-0.18.el6 VDSM: vdsm-4.17.8-1.el7ev How reproducible: All the time (manually and on automation test) Steps to Reproduce: 1. Create new VM 2. Export VM to export domain 3. Remove VM 4. Import VM Note: In automation the vm name is "export_vm" in manual check the vm name is "export_test" Actual results: Failed to import VM: "Internal Engine Error" Expected results: Import VM succeeded Additional info: From the engine log it looks like the engine says that the vm exists. (The remove vm succeed, there is no vm with this name) Engine log: 2015-10-08 15:10:24,990 ERROR [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-7) [482b73ae] Correlation ID: vms_syncAction_1c1b246c-bbcb-4d2f, Job ID: be98fefb-769b-4430-9d0a-b79e2a970e8f, Call Stack: null, Custom Event ID: -1, Message: Failed to import Vm export_vm to Data Center golden_env_mixed, Cluster golden_env_mixed_1 2015-10-08 15:10:25,026 INFO [org.ovirt.engine.core.bll.ImportVmCommand] (ajp-/127.0.0.1:8702-7) [482b73ae] Lock freed to object 'EngineLock:{exclusiveLocks='[export_vm=<VM_NAME, ACTION_TYPE_FAILED_NAME_ALREADY_USED>, 41029e5b-cd0e-498f-ae71-2f897d5c129f=<VM, ACTION_TYPE_FAILED_VM_IS_BEING_IMPORTED$VmName export_vm>]', sharedLocks='[41029e5b-cd0e-498f-ae71-2f897d5c129f=<REMOTE_VM, ACTION_TYPE_FAILED_VM_IS_BEING_IMPORTED$VmName export_vm>]'}' 2015-10-08 15:10:25,027 ERROR [org.ovirt.engine.api.restapi.resource.AbstractBackendResource] (ajp-/127.0.0.1:8702-7) [] Operation Failed: [Internal Engine Error] QE- Automation Engineer int phone - 8272109 mobile - 052-4406697
Created attachment 1081035 [details] autmation_log_engine
Created attachment 1081037 [details] autmation_log_hosts
Created attachment 1081038 [details] manual_check_engine_log
*** Bug 1269930 has been marked as a duplicate of this bug. ***
seems like import fails because of new storage validations in copy image command: 2015-10-08 13:30:56,623 INFO [org.ovirt.engine.core.bll.ImportVmTemplateCommand] (org.ovirt.thread.pool-7-thread-41) [7dea2b6b] Running command: ImportVmTemplateCommand internal: false. Entities affected : ID: 18af3aae-92c2-4c0c-8315-2d67a988a0e3 Type: StorageAction group IMPORT_EXPORT_VM with role type ADMIN 2015-10-08 13:30:57,052 WARN [org.ovirt.engine.core.bll.CopyImageGroupCommand] (org.ovirt.thread.pool-7-thread-41) [f1da6d8] CanDoAction of action 'CopyImageGroup' failed for user admin@internal. Reasons: VAR__TYPE__STORAGE__DOMAIN 2015-10-08 13:30:57,053 INFO [org.ovirt.engine.core.utils.transaction.TransactionSupport] (org.ovirt.thread.pool-7-thread-41) [f1da6d8] transaction rolled back 2015-10-08 13:30:57,053 ERROR [org.ovirt.engine.core.bll.ImportVmTemplateCommand] (org.ovirt.thread.pool-7-thread-41) [f1da6d8] Command 'org.ovirt.engine.core.bll.ImportVmTemplateCommand' failed: EngineException: ENGINE (Failed with error ENGINE and code 5001) i could also reproduce this locally with latest master. Vered, can you please take a look?
Omer, seems like this is the exception that fails the operation: 2015-10-08 15:39:10,963 ERROR [org.ovirt.engine.core.bll.ImportVmTemplateCommand] (org.ovirt.thread.pool-7-thread-4) [5d845592] Exception: java.lang.NumberFormatException: null at java.lang.Long.parseLong(Long.java:552) [rt.jar:1.8.0_51] at org.ovirt.engine.core.utils.MacAddressRangeUtils.macToLong(MacAddressRangeUtils.java:122) [utils.jar:] It fails upon adding the devices so it's probably not a storage validation issue, can someone from you team have a look?
The issue occurred locally without Any other exceptions. CopyImageGroupCommand CDA fails since the disk is null (as it should be since the VM was removed). Some time ago there was no CDA for this command a all. This was fixed in the patch. The same scenario is faulty (and now fixed) for ImportVMTemplate. I recommend verifying them both in this bz with this commit.
OK, but this still leaves the issue of the device copying that fails with NumberFormatException Omer, might be a good idea to see if there's a virt bug there
yes, i did take a look, cant see the reason for that, also tried to reproduce locally and failed on the can-do-action failure. if it would consist after this is fixed, i'll try again and look deeper
*** Bug 1270022 has been marked as a duplicate of this bug. ***
*** Bug 1266930 has been marked as a duplicate of this bug. ***
Verified in 3.6.0-16 with NFS/ISCSI with vms and templates. Omer: is there any specific input to reproduce this NumberFormatException? is virt related? I'm marking this as verified (since from the storage part the bug is fixed)
(In reply to Carlos Mestre González from comment #14) > Verified in 3.6.0-16 with NFS/ISCSI with vms and templates. > > Omer: is there any specific input to reproduce this NumberFormatException? No, i could not reproduce this myself as well. > is virt related? I'm marking this as verified (since from the storage part > the bug is fixed) if that exception would happen at some point, it should be a different bug. this one tracks the storage validation issue
RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE