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
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.
Maor, please provide steps to do it
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>
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.
Maor, once bug 1138124 is fixed, do we have any other AIs here?
(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.
> 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
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.
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"
moving to QA, as rc build vt13.3 was done and according to comment #8, bug is fixed.
verified on vt13.4
RHEV-M 3.5.0 has been released, closing this bug.