Am 28.01.2019 um 09:50 hat Peter Krempa geschrieben:
> On Fri, Jan 25, 2019 at 18:46:52 +0100, Kevin Wolf wrote:
> > The new device_id property specifies which value to use for the vendor
> > specific designator in the Device Identification VPD page.
> >
> > In particular, this is necessary for libvirt to maintain guest ABI
> > compatibility when no serial number is given and a VM is switched from
> > -drive (where the BlockBackend name is used) to -blockdev (where the
> > vendor specific designator is left out by default).
> >
> > Signed-off-by: Kevin Wolf <kwolf@xxxxxxxxxx>
> > ---
> > hw/scsi/scsi-disk.c | 24 ++++++++++++++++--------
> > 1 file changed, 16 insertions(+), 8 deletions(-)
>
> [...]
>
> > @@ -2904,7 +2910,9 @@ static const TypeInfo scsi_disk_base_info = {
> > DEFINE_PROP_STRING("ver", SCSIDiskState, version), \
> > DEFINE_PROP_STRING("serial", SCSIDiskState, serial), \
> > DEFINE_PROP_STRING("vendor", SCSIDiskState, vendor), \
> > - DEFINE_PROP_STRING("product", SCSIDiskState, product)
> > + DEFINE_PROP_STRING("product", SCSIDiskState, product), \
> > + DEFINE_PROP_STRING("device_id", SCSIDiskState, device_id)
>
> This adds the property only to 'scsi-disk', whereas libvirt will use
> 'scsi-cd' or 'scsi-hd' depending on the media type if the 'scsi-cd'
> device is detected.
I'm adding this to the macro DEFINE_SCSI_DISK_PROPERTIES(), which is
used for scsi-hd, scsi-cd and scsi-disk.
It is not added to scsi-block, but there we pass through the VPD page of
the real disk, so this looks correct to me.
> The following logic decides:
>
> https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_command.c;h=3e46f3ced3c1e6a4865e98e2d0cdce3214c4a5d2;hb=HEAD#l1978
>
> This brings multiple questions:
>
> 1) Is this necssary also for scsi-cd/scsi-hd and if yes, the property
> does not seem to be present for those
Yes, but the property is added there.
> 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.
> 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.
Kevin
Attachment:
signature.asc
Description: PGP signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
