[libvirt] [Qemu-devel] [PATCH 2/3] scsi-disk: Add device_id property
Peter Krempa
pkrempa at redhat.com
Tue Jan 29 09:40:35 UTC 2019
On Mon, Jan 28, 2019 at 17:55:14 +0100, Markus Armbruster wrote:
> Kevin Wolf <kwolf at redhat.com> writes:
>
> > Am 28.01.2019 um 09:50 hat Peter Krempa geschrieben:
> [...]
> >> 2) Is actually using 'scsi-cd'/'scsi-hd' the better option than
> >> 'scsi-disk'?
> >
> > Yes, scsi-disk is a legacy device. Maybe we should formally deprecate
> > it.
>
> There's an internal use in scsi_bus_legacy_add_drive(), which in turn
> powers two legacy features:
>
> 1. -drive if=scsi
>
> Creates scsi-disk frontends.
>
> Only works with onboard HBAs since commit 14545097267, v2.12.0.
>
> 2. -device usb-storage
>
> Bad magic: usb-storage pretends to be a block device, but it's really
> a SCSI bus that can serve only a single device, which it creates
> automatically.
>
> If we deprecate scsi-disk, we should deprecate these, too. Can't say
> whether that's practical right now.
Unfortunately we did not bother replacing usb-storage yet.
scsi-disk was unused for some time (if scsi-hd was supported). I just
deleted any mentions of it from libvirt now.
>
> >> 3) Since upstream libvirt supports qemu-1.5 and newer and 'scsi-cd' is
> >> already supported there, can we assume that all newer versions support
> >> it? (Basically the question is whether it can be compiled out by
> >> upstream means).
> >
> > I think so.
>
> Compiling out scsi-hd or scsi-cd, but not scsi-disk would be silly. All
> three devices are in scsi-disk.c. You'd have to hack that up to be
> silly.
That would be a downstream modification of qemu thus libvirt will
not want to support that.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20190129/858d3a3a/attachment-0001.sig>
More information about the libvir-list
mailing list