Bug 1147251

Summary: [BlockDev] OvfStore fails to update as a result of dc removal,'Error parsing OVF due to null'.
Product: Red Hat Enterprise Virtualization Manager Reporter: Ori Gofen <ogofen>
Component: ovirt-engineAssignee: Maor <mlipchuk>
Status: CLOSED CURRENTRELEASE QA Contact: Ori Gofen <ogofen>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 3.5.0CC: acanan, amureini, ecohen, eedri, gklein, iheim, lpeer, lsurette, mlipchuk, ogofen, rbalakri, Rhev-m-bugs, scohen, tnisan, yeylon
Target Milestone: ---Flags: scohen: Triaged+
Target Release: 3.5.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: storage
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 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: 1138124    
Bug Blocks:    
Attachments:
Description Flags
vdsm+engine logs none

Description Ori Gofen 2014-09-28 12:41:25 UTC
Created attachment 941981 [details]
vdsm+engine logs

Description of problem:
when removing a data center which had one Block master domain with entities.
OvfStore file fails to update upon a successful re-attach to a new dc

from engine's log:
"2014-09-28 15:22:07,223 ERROR [org.ovirt.engine.core.utils.ovf.OvfManager] (ajp-/127.0.0.1:8702-3) Error parsing OVF due to null"
Version-Release number of selected component (if applicable):
vt3.1

How reproducible:
100%

Steps to Reproduce:
1.have dc with one Block domain
2.execute script-or create 5 vm's+disks
3.maintain the domain,remove dc
4.create new dc,attach the cluster back,attach the domain back
5.execute script
Actual results:
OvfStore fails to update,probably due to errors in iscsi connectivity

Expected results:
no Fail

Additional info:
rhel 6.5

Comment 1 Maor 2014-09-30 12:25:46 UTC
Ori, can u please reproduce this with debug log level.
I see In the code that we have more information on the OVF String, but I can't see this in the log since it prints only info.

Comment 2 Maor 2014-09-30 12:26:05 UTC
Ori, can u please reproduce this with debug log level.
I see In the code that we have more information on the OVF String, but I can't see this in the log since it prints only info.

Comment 3 Ori Gofen 2014-10-01 12:21:46 UTC
Maor, please provide steps to do it

Comment 4 Maor 2014-10-20 08:10:56 UTC
The file that should be changed is ovirt-engine.xml.in

Once you find it in your env, you should change the category of the bll project from INFO to DEBUG as so:
<logger category="org.ovirt.engine.core.bll">
    <level name="DEBUG"/>
</logger>

Comment 5 Ori Gofen 2014-10-20 12:02:48 UTC
The origin of this bug probably refers to BZ #1138124, the unregistered_entities  psql ovf field is trying to be updated from a null field.

waiting to be verified after BZ #1138124 will be ON_QA. or in case this bugs are unrelated for further exploring.

Comment 6 Allon Mureinik 2014-12-08 13:41:53 UTC
Maor, once bug 1138124 is fixed, do we have any other AIs here?

Comment 7 Maor 2014-12-09 13:06:01 UTC
(In reply to Allon Mureinik from comment #6)
> Maor, once bug 1138124 is fixed, do we have any other AIs here?

Error parsing OVF duo to null, happens when the user pick the sub tab of "VM Import" or "Template Import" and we fail to parse the OVF which contained there.

Currently this bug is related to the procedure of moving a Storage Domain to maintenance before the OVF_STORE disk, or the DB table was updated with the OVF xml data.

so for that particular case, this bug should be solved.
although, take in consider that this error ("Error parsing OVF duo to null") is a general error which might appear from time to time when we fail to parse an xml.

Comment 8 Tal Nisan 2014-12-09 14:06:30 UTC
> so for that particular case, this bug should be solved.
> although, take in consider that this error ("Error parsing OVF duo to null")
> is a general error which might appear from time to time when we fail to
> parse an xml.

Moving to MODIFIED then

Comment 9 Maor 2014-12-09 14:25:11 UTC
This bug was caused since the entities in the Data Base were not updated in the table since the OVF_STORE did not executed yet.
It can be reproduced by creating a new Storage domain create Vms with disks on it and detach it from the DC right after.
in this case the table which contains the OVF data still was not updated with the OVF XML and that cause a problem every time we try to see if there are candidates to import on the new Storage Domain

bug 1138124 fix this issue by updating the DB table when moving the Storage Domain to maintenance.

Comment 10 Maor 2014-12-09 16:16:37 UTC
The reproduce steps should be as follow:
1. Verify that OvfUpdateIntervalInMinutes is 60 minutes in the Data Base at the vdc_options table
2. Start your engine
This operation should take less then 60 minutes:
3. Create a new Storage Domain
4. Crate a VM/Template with disks on this Storage Domain
5. Maintain the Storage Domain
At this point the DB table vm_ovf_generations should be updated with the VM OVFs (this was the fix, before that the OVF_DATA was null)
6. Detach the Storage Domain
7. Attach the Storage Domain to a new 3.5 DC and activate it
8. Go to main tab Storage Domains -> Go to sub tab "VMs Import" or Templates Import"
9. Check the log for the error "Error parsing OVF duo to null"

Expected result:
There should not be error "Error parsing OVF duo to null"

Comment 11 Eyal Edri 2014-12-14 17:42:38 UTC
moving to QA, as rc build vt13.3 was done and according to comment #8, bug is fixed.

Comment 12 Ori Gofen 2014-12-21 15:27:24 UTC
verified on vt13.4

Comment 13 Allon Mureinik 2015-02-16 19:13:02 UTC
RHEV-M 3.5.0 has been released, closing this bug.

Comment 14 Allon Mureinik 2015-02-16 19:13:04 UTC
RHEV-M 3.5.0 has been released, closing this bug.