Re: [PATCH 0/6] qemu: Fix cdrom as SCSI hostdev via -blockdev

Sent: Tuesday, October 20, 2020 at 3:22 PM From: "Peter Krempa" <pkrempa(a)redhat.com&gt; To: "daggs" <daggs(a)gmx.com&gt; Cc: libvir-list(a)redhat.com Subject: Re: [PATCH 0/6] qemu: Fix cdrom as SCSI hostdev via -blockdev Oh, so your guest OS doesn't seem to recognize virtio-scsi apparently! On my test VM I've got the following: $ ls -lia /sys/bus/scsi/devices total 0 5659 drwxr-xr-x. 2 root root 0 Oct 19 17:34 . 5657 drwxr-xr-x. 4 root root 0 Oct 19 17:34 .. 18418 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 0:0:0:0 -> ../../../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0 20322 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 6:0:0:1 -> ../../../devices/pci0000:00/0000:00:02.7/0000:08:00.0/virtio6/host6/target6:0:0/6:0:0:1 19773 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 6:0:0:3 -> ../../../devices/pci0000:00/0000:00:02.7/0000:08:00.0/virtio6/host6/target6:0:0/6:0:0:3 15523 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host0 -> ../../../devices/pci0000:00/0000:00:1f.2/ata1/host0 15571 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host1 -> ../../../devices/pci0000:00/0000:00:1f.2/ata2/host1 15619 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host2 -> ../../../devices/pci0000:00/0000:00:1f.2/ata3/host2 15667 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host3 -> ../../../devices/pci0000:00/0000:00:1f.2/ata4/host3 15715 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host4 -> ../../../devices/pci0000:00/0000:00:1f.2/ata5/host4 15763 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host5 -> ../../../devices/pci0000:00/0000:00:1f.2/ata6/host5 19403 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 host6 -> ../../../devices/pci0000:00/0000:00:02.7/0000:08:00.0/virtio6/host6 18376 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 target0:0:0 -> ../../../devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0 19733 lrwxrwxrwx. 1 root root 0 Oct 19 17:34 target6:0:0 -> ../../../devices/pci0000:00/0000:00:02.7/0000:08:00.0/virtio6/host6/target6:0:0 You can see that host6 is a virtio-scsi controller and it has targets. You need to figure out why your guest doesn't have the driver. Alternative would be to use a different scsi controller model, but any emulated will result in overhead, so the best solution will be to get drivers. Sorry I've mislead you with the initial red herring, but your report really came after I've modified how we do hostdevs so I thought I messed up something.