Created attachment 1133534 [details] engine.log and vdsm.log Hi, I have a oVirt Setup which includes two host. The first host is also running the oVirt engine. Today I installed a couple VMs on the second host from USB without any issue. Now I tried to perform this also on the first host but it looks like the USB is not accessible. I'm able to add the device to the host but I can see the following message in the engine.log which does not look correct. I'm running oVirt 3.6.3.4-1.el7.centos Let me know if you need more information. Best regards Christoph oVirt User List Thread: http://lists.ovirt.org/pipermail/users/2016-March/038276.html
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. ***