Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 1269948
Summary: | Failed to import VM / VM Template | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | Red Hat Enterprise Virtualization Manager | Reporter: | Israel Pinto <ipinto> | ||||||||
Component: | ovirt-engine | Assignee: | Vered Volansky <vered> | ||||||||
Status: | CLOSED CURRENTRELEASE | QA Contact: | Kevin Alon Goldblatt <kgoldbla> | ||||||||
Severity: | urgent | Docs Contact: | |||||||||
Priority: | urgent | ||||||||||
Version: | 3.6.0 | CC: | acanan, amureini, cmestreg, danken, gklein, juzhou, lsurette, michal.skrivanek, mmucha, mxie, rbalakri, redhat, Rhev-m-bugs, rjones, tlitovsk, tnisan, tzheng, vered, yeylon, ykaul, ylavi | ||||||||
Target Milestone: | ovirt-3.6.0-rc3 | Keywords: | AutomationBlocker, Regression | ||||||||
Target Release: | 3.6.0 | ||||||||||
Hardware: | Unspecified | ||||||||||
OS: | Unspecified | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2016-03-10 10:35:21 UTC | Type: | Bug | ||||||||
Regression: | --- | Mount Type: | --- | ||||||||
Documentation: | --- | CRM: | |||||||||
Verified Versions: | Category: | --- | |||||||||
oVirt Team: | Storage | RHEL 7.3 requirements from Atomic Host: | |||||||||
Cloudforms Team: | --- | Target Upstream Version: | |||||||||
Embargoed: | |||||||||||
Bug Depends On: | |||||||||||
Bug Blocks: | 910269 | ||||||||||
Attachments: |
|
Description
Israel Pinto
2015-10-08 14:44:52 UTC
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 RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE RHEV 3.6.0 has been released, setting status to CLOSED CURRENTRELEASE |