Bug 1692100 - libvirtd says "Failed to open file '/sys/class/scsi_host/.../unique_id': No such file or directory" on every usb storage unplug
Summary: libvirtd says "Failed to open file '/sys/class/scsi_host/.../unique_id': No s...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: libvirt
Version: 33
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Libvirt Maintainers
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-03-24 10:22 UTC by Zbigniew Jędrzejewski-Szmek
Modified: 2021-01-05 01:25 UTC (History)
12 users (show)

Fixed In Version: libvirt-6.6.0-5.fc33
Clone Of:
Environment:
Last Closed: 2021-01-05 01:25:29 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)

Description Zbigniew Jędrzejewski-Szmek 2019-03-24 10:22:00 UTC
Description of problem:
libvirts logs this at error level. I guess it just means that the device is gone and libvirtd cannot access details about it. Please make libvirtd not log anything.

Mar 19 13:16:45 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 19 13:18:31 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 19 13:18:31 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 19 17:42:21 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host2/unique_id': No such file or directory
Mar 22 07:43:31 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 24 10:28:42 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 24 10:30:25 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
Mar 24 11:16:48 krowka libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory

Version-Release number of selected component (if applicable):
libvirt-daemon-5.1.0-1.fc30.x86_64
kernel-core-4.20.16-200.fc29.x86_64

Comment 1 Erik Skultety 2019-03-25 08:49:55 UTC
What kind of scsi device does one need to reproduce? You need to provide some kind of reproducer here, to help us investigate the issue closer. Daemon debug logs *with* appropriate filters applied would also help, see: https://wiki.libvirt.org/page/DebugLogs

Comment 2 Zbigniew Jędrzejewski-Szmek 2019-03-25 09:08:59 UTC
Oh, just a plain "usb stick" storage.

$ journalctl --no-hostname -o short-monotonic -f 
(plug in)
[581669.720689] kernel: usb 1-1: new high-speed USB device number 52 using xhci_hcd
[581669.848357] kernel: usb 1-1: New USB device found, idVendor=090c, idProduct=1000, bcdDevice=11.00
[581669.848387] kernel: usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[581669.848397] kernel: usb 1-1: Product: USB Flash Disk
[581669.848405] kernel: usb 1-1: Manufacturer: General
[581669.848413] kernel: usb 1-1: SerialNumber: 0410240000006579
[581669.869204] kernel: usb-storage 1-1:1.0: USB Mass Storage device detected
[581669.870154] kernel: scsi host3: usb-storage 1-1:1.0
[581675.180876] mtp-probe[20499]: checking bus 1, device 52: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
[581675.184933] mtp-probe[20499]: bus: 1, device: 52 was not an MTP device
[581675.263228] mtp-probe[20504]: checking bus 1, device 52: "/sys/devices/pci0000:00/0000:00:14.0/usb1/1-1"
[581675.263783] mtp-probe[20504]: bus: 1, device: 52 was not an MTP device
[581671.448340] kernel: scsi 3:0:0:0: Direct-Access     General  USB Flash Disk   1100 PQ: 0 ANSI: 4
[581671.449712] kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0
[581671.449745] kernel: sd 3:0:0:0: Embedded Enclosure Device
[581671.449806] kernel: sd 3:0:0:0: [sdc] 15728640 512-byte logical blocks: (8.05 GB/7.50 GiB)
[581671.450349] kernel: sd 3:0:0:0: Failed to get diagnostic page 0x1
[581671.450361] kernel: sd 3:0:0:0: Failed to bind enclosure -19
[581671.450772] kernel: sd 3:0:0:0: [sdc] Write Protect is off
[581671.450787] kernel: sd 3:0:0:0: [sdc] Mode Sense: 43 00 00 00
[581671.451273] kernel: sd 3:0:0:0: [sdc] No Caching mode page found
[581671.451283] kernel: sd 3:0:0:0: [sdc] Assuming drive cache: write through
[581671.454787] kernel:  sdc: sdc1
[581671.464771] kernel: sd 3:0:0:0: [sdc] Attached SCSI removable disk
(plug out)
[581674.272423] kernel: usb 1-1: USB disconnect, device number 52
[581679.613289] libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory
[581679.628181] libvirtd[1958]: Failed to open file '/sys/class/scsi_host/host3/unique_id': No such file or directory

Comment 3 Ben Cotton 2019-08-13 17:11:32 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to '31'.

Comment 4 Ben Cotton 2019-08-13 19:30:03 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 31 development cycle.
Changing version to 31.

Comment 5 hodiko.v 2019-08-14 20:21:17 UTC
Hello, i have a similar error, but it's related to storages that don't exist in system anymore. For example i have created a VM with storage '/mnt/archlinux_lvm_70G_branch.qcow2' and with install media '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO' attached. After i delete this vm, but leave vm storage resources untouched in manager, but delete them manually - libvirt will log mentioned errors every 3 seconds. Is it possible to disable them?
I tried to use log_filters, but i don't know how to disable logging of this specific error since it's already the least descriptive one and i dont know where from it comes.

log_filters="5:virfile 5:storage 2:qemu 2:libvirt 4:object 4:json 4:event 2:util"

-----------------------------------------------
$ libvirtd -V
libvirtd (libvirt) 5.5.0
$ virt-manager --version
2.2.0

------------------------------------------------
$ journalctl -p err --since "1 minutes ago"
Aug 14 23:02:02 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:02 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:02 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:02 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:05 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:05 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:05 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:05 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:08 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:08 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:08 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:08 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:11 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:11 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:11 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:11 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:14 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:14 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:14 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:14 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:17 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:17 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:17 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:17 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:20 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:20 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:20 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:20 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:23 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:23 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:23 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:23 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:26 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:26 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:26 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:26 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:29 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:29 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:29 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:29 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:32 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory
Aug 14 23:02:32 hyper libvirtd[1070]: Failed to open file '/dev/sde': No such file or directory
Aug 14 23:02:32 hyper libvirtd[1070]: Failed to open file '/mnt/super_grub2_disk_hybrid_2.02s10.iso': No such file or directory
Aug 14 23:02:32 hyper libvirtd[1070]: Failed to open file '/mnt/archlinux_lvm_70G_branch.qcow2': No such file or directory
Aug 14 23:02:35 hyper libvirtd[1070]: Failed to open file '/media/data/downloads/Windows 10 Enterprise LTSC  x64 by Zosma (15.01.2019).ISO': No such file or directory

Comment 6 Ben Cotton 2020-11-03 15:12:11 UTC
This message is a reminder that Fedora 31 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 31 on 2020-11-24.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '31'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 31 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Comment 7 Zbigniew Jędrzejewski-Szmek 2020-11-03 16:50:56 UTC
Still an issue with libvirt-daemon-6.6.0-2.fc33.x86_64.

Comment 8 Ján Tomko 2020-11-04 12:01:53 UTC
Proposed upstream patch:
https://www.redhat.com/archives/libvir-list/2020-November/msg00164.html

Comment 9 Ján Tomko 2020-11-06 14:12:42 UTC
Pushed upstream as:
commit 4a56278e770c972dbee7be5842b557de152a586e
Author:     Ján Tomko <jtomko>
CommitDate: 2020-11-06 15:03:39 +0100

    util: quieten virSCSIHostGetUniqueId
    
    The only caller of this function ignores failure
    and just sets the unique_id to -1.
    
    Failing to read the file is likely to the device no longer
    being present, not a real error.
    
    Stop reporting errors in this function.
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1692100
    
    Signed-off-by: Ján Tomko <jtomko>
    Reviewed-by: Erik Skultety <eskultet>

git describe: v6.9.0-106-g4a56278e77

It should be fixed in upstream release 6.10.0

Comment 10 Fedora Update System 2020-12-07 18:33:43 UTC
FEDORA-2020-7f42597eb4 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f42597eb4

Comment 11 Fedora Update System 2020-12-08 16:53:00 UTC
FEDORA-2020-7f42597eb4 has been pushed to the Fedora 33 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-7f42597eb4`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-7f42597eb4

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2021-01-05 01:25:29 UTC
FEDORA-2020-7f42597eb4 has been pushed to the Fedora 33 stable repository.
If problem still persists, please make note of it in this bug report.


Note You need to log in before you can comment on or make changes to this bug.