Bug 1315100
| Summary: | Command 'org.ovirt.engine.core.bll.hostdev.RefreshHostDevicesCommand' failed: Failed managing transaction | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [oVirt] ovirt-engine | Reporter: | Christoph <ovirt> | ||||||
| Component: | General | Assignee: | Martin Betak <mbetak> | ||||||
| Status: | CLOSED CURRENTRELEASE | QA Contact: | Nisim Simsolo <nsimsolo> | ||||||
| Severity: | medium | Docs Contact: | |||||||
| Priority: | unspecified | ||||||||
| Version: | 3.6.3.3 | CC: | bugs, gklein, mbetak, mburman, michal.skrivanek, mkalfon, mperina, mpoledni, nicolas, nsimsolo, ovirt, tjelinek | ||||||
| Target Milestone: | ovirt-4.0.2 | Flags: | rule-engine:
ovirt-4.0.z+
rule-engine: planning_ack+ rule-engine: devel_ack+ rule-engine: testing_ack+ |
||||||
| Target Release: | 4.0.2.1 | ||||||||
| Hardware: | x86_64 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | Environment: | ||||||||
| Last Closed: | 2016-08-22 12:32:30 UTC | Type: | Bug | ||||||
| Regression: | --- | Mount Type: | --- | ||||||
| Documentation: | --- | CRM: | |||||||
| Verified Versions: | Category: | --- | |||||||
| oVirt Team: | Virt | RHEL 7.3 requirements from Atomic Host: | |||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||
| Embargoed: | |||||||||
| Bug Depends On: | 1306333 | ||||||||
| Bug Blocks: | |||||||||
| Attachments: |
|
||||||||
|
Description
Christoph
2016-03-06 17:03:52 UTC
Martin, could you please take a look? Hi Christoph, please provide server.log so we can see the underlying cause of the transaction failure. If I had to guess I'd say this is another manifestation of BZ#1306333 but let's wait for the server.log Created attachment 1133874 [details]
server.log
Hi,
please find the server.log in the attachment.
Best regards
Christoph
Yes I can confirm this is a consequence of libvirt BZ#1306333 because it sends internaly inconsistent host devices to VDSM - more specifically the device named scsi_host8 is specified as parent of one device but not included in the listing. Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on table "host_device" violates foreign key constraint "fk_host_device_parent_name" Detail: Key (host_id, parent_device_name)=(548efa0a-d053-4189-b45d-a0134270573f, scsi_host8) is not present in table "host_device". I believe the best current workaround is the restart of libvirt daemon, then the reported devices should become internally consistent again and the RefreshHostDevicesCommand should succeed. (In reply to Martin Betak from comment #5) > Yes I can confirm this is a consequence of libvirt BZ#1306333 because it > sends internaly inconsistent host devices to VDSM - more specifically the > device named scsi_host8 is specified as parent of one device but not > included in the listing. > > Caused by: org.postgresql.util.PSQLException: ERROR: insert or update on > table "host_device" violates foreign key constraint > "fk_host_device_parent_name" > Detail: Key (host_id, > parent_device_name)=(548efa0a-d053-4189-b45d-a0134270573f, scsi_host8) is > not present in table "host_device". > > I believe the best current workaround is the restart of libvirt daemon, then > the reported devices should become internally consistent again and the > RefreshHostDevicesCommand should succeed. Hi Martin, it is possible to do that without stopping the VMs or should I stop all VMs first. Best regards Christoph Hi Christoph, I believe the proper *supported* way is to put the host to maintenance mode and only then you should restart some services on that host. However. ----- BEGIN UNSUPPORTED ADVICE ----- In this instance my best judgement tells me this *should* be ok (restart just the libvirtd) and the system should survive this. (restarting vdsmd usually causes problems outside maint. mode), but note that in this case you are on your own. ----- END UNSUPPORTED ADVICE ----- Hope this helps :-) Best regards, Martin any news? (In reply to Tomas Jelinek from comment #8) > any news? Hi Tomas, I have to plan the shutdown for the VMs as they are in production. Please let me know if it is important to get the feedback regarding the restart of the libvirt daemon. If yes I could try to perform it on the weekend. Best regards Christoph Hi Christoph, no, not that important. *** Bug 1336193 has been marked as a duplicate of this bug. *** After further consideration, the bug should be fixed at engine level. VDSM does not work with assumption that the devices are single tree, and it's not even feasible due to possible filtering by device capability. Trying to "fix" this inside VDSM would create special (incorrect) case for the API verb. *** Bug 1358737 has been marked as a duplicate of this bug. *** Verified: ovirt-engine-4.0.2.7-0.1.el7ev qemu-kvm-rhev-2.3.0-31.el7_2.21.x86_64 vdsm-4.18.11-1.el7ev.x86_64 libvirt-client-1.2.17-13.el7_2.5.x86_64 sanlock-3.2.4-3.el7_2.x86_64 Verification scenario: 1. Insert USB DOK to first host, refresh host capabilities, verify USB DOK is listed in host devices, attach it to VM, run VM and verify USB DOK is accessible from the VM. 2. Disconnect USB DOK from first host, connect it to second host, refresh host capabilities, verify USB DOK is listed in host devices, attach it to VM, run VM and verify USB DOK is accessible from the VM. *** Bug 1395798 has been marked as a duplicate of this bug. *** *** Bug 1395798 has been marked as a duplicate of this bug. *** |