Re: [PATCH v2 0/4] virtio-blk: Deprecate silent truncation of serial

[Kevin Wolf <kwolf@redhat.com>]

Am 13.11.2026 um 17:39 hat Christian Borntraeger geschrieben:
> Am 13.11.26 um 06:31 schrieb Kevin Wolf:
> > Am 09.11.2026 um 14:21 hat Christian Borntraeger geschrieben:
> > > Am 30.10.26 um 00:09 schrieb Kevin Wolf via Devel:
> > > > QEMU has allowed the user to specify serials of arbitrary length for
> > > > virtio-blk devices, even though the virtio-blk protocol can only
> > > > communicate 20 characters of the serial to the guest. This means that a
> > > > longer serial number on the command line is silently truncated to 20
> > > > characters from the guest perspective.
> > > > 
> > > > As a first step to fix this, deprecate the silent truncation and turn it
> > > > into a warning; we can later make this a hard error. While touching
> > > > GET_ID, let's make it more spec compliant and clean up the internal
> > > > state.
> > > > 
> > > > Another part is planned that will actually enable users to use longer
> > > > serials and additional device identifiers. This will need spec changes
> > > > and would take more time than we have until the QEMU 11.2 freeze anyway,
> > > > so I'll address this later. For now, the important thing is to get the
> > > > deprecation period started.
> > > 
> > > Consider me interested for future extensions.
> > > Additional information via virtio-blk would be really helpful. e.g. when
> > > forwarding a scsi LUN having the WWID visible for virtio-blk would be really
> > > nice. One usecase is that the guest visible WWID can be used to talk to
> > > the storage server to create snapshots without having to have a translation
> > > table from guest virtio-blk device to WWID. This was actually a real ask from
> > > a customer.
> > 
> > So let's talk about what specific information to add while we touch the
> > spec. My first thought was adding whatever two or three things scsi-disk
> > offers in qdev, but after actually looking at the code and the spec I'm
> > not so sure any more. We seem to have:
> > 
> > - vendor, product (standard INQUIRY data)
> > - serial (VPD page 0x80)
> > - device_id (VPD page 0x83, vendor-specific descriptor for LUN)
> > - wwn (VPD page 0x83, 64 bit NAA descriptor for LUN)
> > - port_wwn (VPD page 0x83, 64 bit NAA descriptor for SAS target port)
> > - port_index (VPD page 0x83, relative target port identifier for SAS target port)
> > 
> > For comparison, IDE seems to have:
> > 
> > - serial
> > - model
> > - wwn (64 bit NAA descriptor)
> > 
> > As virtio-blk is a single-disk device, it probably makes sense to leave
> > out the non-LUN descriptors from SCSI.
> > 
> > It's also unclear to me that serial vs. device_id is something that
> > would make sense in the context of virtio-blk. I don't really know how
> > to explain an additional device_id in the spec and what would make it
> > different from serial.
> > 
> > Maybe something like vendor/product/model would make sense where we
> > would return "QEMU" and other implementations can return a different
> > string (e.g. if guest drivers have to work around bugs in a specific
> > implementation). Probably just a single field.
> > 
> > And then finally the WWID, where scsi-hd and ide-hd agree that it's a
> > 64 bit number, but the SCSI spec is a lot more complicated. I think we
> > want to have this, but the exact format to use in the virtio spec isn't
> > entirely obvious. I've been thinking of maybe just referencing the SPC
> > and adding the SCSI name string to the spec, which can represent the
> > 64 bit NAA identifiers supported by scsi-hd and ide-hd, but can also
> > express a few more things.
> > 
> > Any thoughts on all of this?
> So I think the wwn is the most critical one.
> For example
> So the KVM host has scsi disks that appear in the guest as
> /dev/disk/by-id/wwn-0x6005076307ffd72c0000000000002079
> /dev/disk/by-id/dm-uuid-mpath-36005076307ffd72c0000000000002179
> 
> passing that through via virtio-blk does not provide this number in the guest.
> passing it along via virtio-scsi as lun I have the same udev device in the
> guest. Having the same for virtio-blk (maybe optionally) would be awesome.

I don't think having it passed through automatically would be a good
idea (migration compatibility etc.). I'm thinking of a qdev property
that lets you specify it, like the existing -device scsi-hd,wwn=...

> > > virtio SCSI LUN passthru has that but it is significantly slower
> > > (factors) and that was also real feedback from that customer.
> > 
> > Does this mean that what the emulated scsi-hd offers is actually not
> > good enough, but you have to use passthrough to enable this use case?
> > What is the additional information they need?

I can see above that your WWID is 128 bits, so what scsi-hd can pass to
the guest is probably not good enough (it's only 64 bit).

That seems to support the idea of using a SCSI name string instead, so
that you could specify something like:

    -device virtio-blk,drive=mydisk,scsi-name=naa.6005076307ffd72c0000000000002079

> It does mean that virtio-blk seems good enough (bandwidth and cpu
> wise) to consolidate database workloads in KVM and virtio-scsi is not.
> Just try fio on the same host nvme with virtio-blk, scsi disk and scsi
> lun. Its getting slower with each step. And only the last variant
> (lun) uses SG_IO to pass along then wwn.

Yes, of course, performance was not my question.

The question was if only passing the wwn gives the guest all the
information it needs or if other parts of the VPD pages or other
information is needed to achieve what you need.

If the existing -scsi-hd,wwn=... were working for you, I would know for
sure that we just need to enable the same thing in virtio-blk and it
will work. If we're comparing with LUN passthrough (scsi-block or
scsi-generic), you're giving the guest access to everything and not just
this one piece of information.

Kevin