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

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

[Kevin Wolf]

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.

v2:
- Drop truncation of qdev property for now [Stefan]
- Add test case for exactly 20 characters [Stefan]
- Fix missing guest_free() [Stefan]
- Pass pattern_byte to get_id_request() instead of hardcoding it
  [Stefan]

Kevin Wolf (4):
  virtio-blk: Implement full NUL padding for GET_ID
  virtio-blk-test: Add a basic GET_ID test case
  virtio-blk: Deprecate silent truncation of serial
  virtio-blk-test: Test truncated serial

 docs/about/deprecated.rst     |  13 ++++
 hw/block/virtio-blk.c         |  18 +++--
 tests/qtest/virtio-blk-test.c | 119 ++++++++++++++++++++++++++++++++++
 3 files changed, 146 insertions(+), 4 deletions(-)

-- 
2.56.0

[PATCH v2 1/4] virtio-blk: Implement full NUL padding for GET_ID

[Kevin Wolf]

The spec requires not only NUL termination of the device ID string, but
NUL padding:

    VIRTIO_BLK_T_GET_ID requests fetch the device ID string from the
    device into data. The device ID string is a NUL-padded ASCII string
    up to 20 bytes long. If the string is 20 bytes long then there is no
    NUL terminator.

Zero out all of the remaining bytes in the request buffer.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 hw/block/virtio-blk.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 536d71a91ad..3f236f22d57 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1011,14 +1011,18 @@ static int virtio_blk_handle_request(VirtIOBlockReq *req, MultiReqBuffer *mrb)
     case VIRTIO_BLK_T_GET_ID:
     {
         /*
-         * NB: per existing s/n string convention the string is
+         * The spec requires NUL-padding for the output. The string is
          * terminated by '\0' only when shorter than buffer.
          */
         const char *serial = s->conf.serial ? s->conf.serial : "";
-        size_t size = MIN(strlen(serial) + 1,
-                          MIN(iov_size(in_iov, in_num),
-                              VIRTIO_BLK_ID_BYTES));
+        size_t req_size = MIN(iov_size(in_iov, in_num), VIRTIO_BLK_ID_BYTES);
+        size_t size = MIN(strlen(serial), req_size);
+        size_t padding = req_size - size;
+
         iov_from_buf(in_iov, in_num, 0, serial, size);
+        if (padding) {
+            iov_memset(in_iov, in_num, size, 0, padding);
+        }
         virtio_blk_req_complete(req, VIRTIO_BLK_S_OK);
         g_free(req);
         break;
-- 
2.56.0

[PATCH v2 2/4] virtio-blk-test: Add a basic GET_ID test case

[Kevin Wolf]

This covers the simple common case with no surprises: A serial that is
shorter than 20 characters and can fit in the request buffer.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 tests/qtest/virtio-blk-test.c | 96 +++++++++++++++++++++++++++++++++++
 1 file changed, 96 insertions(+)

diff --git a/tests/qtest/virtio-blk-test.c b/tests/qtest/virtio-blk-test.c
index 98c906ebb4a..825ea261bed 100644
--- a/tests/qtest/virtio-blk-test.c
+++ b/tests/qtest/virtio-blk-test.c
@@ -95,6 +95,8 @@ static uint64_t virtio_blk_request(QGuestAllocator *alloc, QVirtioDevice *d,
         g_assert_cmpuint(data_size %
                          sizeof(struct virtio_blk_discard_write_zeroes), ==, 0);
         break;
+    case VIRTIO_BLK_T_GET_ID:
+        break;
     default:
         g_assert_cmpuint(data_size, ==, 0);
     }
@@ -771,6 +773,91 @@ static void resize(void *obj, void *data, QGuestAllocator *t_alloc)
 
 }
 
+static QVirtQueue *get_id_setup(QVirtioDevice *dev, QGuestAllocator *t_alloc)
+{
+    QVirtQueue *vq;
+    uint64_t features = qvirtio_get_features(dev);
+
+    features = features & (1ull << VIRTIO_F_VERSION_1);
+    qvirtio_set_features(dev, features);
+
+    vq = qvirtqueue_setup(dev, t_alloc, 0);
+    qvirtio_set_driver_ok(dev);
+    return vq;
+}
+
+static uint8_t get_id_request(QVirtioDevice *dev, QVirtQueue *vq,
+                              char *buf, size_t buf_len,
+                              char pattern_byte,
+                              QGuestAllocator *t_alloc)
+{
+    QTestState *qts = global_qtest;
+    uint64_t req_addr;
+    uint32_t free_head;
+    uint8_t status;
+
+    QVirtioBlkReq req = {
+        .type = VIRTIO_BLK_T_GET_ID,
+        .data = buf,
+    };
+
+    req_addr = virtio_blk_request(t_alloc, dev, &req, buf_len);
+
+    memset(req.data, pattern_byte, buf_len);
+    memwrite(req_addr + 16, req.data, buf_len);
+
+    free_head = qvirtqueue_add(qts, vq, req_addr, 16, false, true);
+    qvirtqueue_add(qts, vq, req_addr + 16, buf_len, true, true);
+    qvirtqueue_add(qts, vq, req_addr + 16 + buf_len, 1, true, false);
+
+    qvirtqueue_kick(qts, dev, vq, free_head);
+
+    qvirtio_wait_used_elem(qts, dev, vq, free_head, NULL,
+                           QVIRTIO_BLK_TIMEOUT_US);
+    status = readb(req_addr + 16 + buf_len);
+    memread(req_addr + 16, buf, buf_len);
+
+    guest_free(t_alloc, req_addr);
+
+    return status;
+}
+
+static void get_id_serial_short(void *obj, void *data, QGuestAllocator *t_alloc)
+{
+    QVirtioBlk *blk_if = obj;
+    QVirtioDevice *dev = blk_if->vdev;
+    QVirtQueue *vq;
+    uint8_t status;
+    const char expected[20] = "abc";
+    char buf[20];
+
+    vq = get_id_setup(dev, t_alloc);
+    status = get_id_request(dev, vq, buf, 20, 0xa5, t_alloc);
+    g_assert_cmpint(status, ==, 0);
+    g_assert_cmpmem(buf, 20, expected, sizeof(expected));
+
+    qvirtqueue_cleanup(blk_if->vdev->bus, vq, t_alloc);
+}
+
+static void get_id_serial_short_20_characters(void *obj, void *data,
+                                              QGuestAllocator *t_alloc)
+{
+    QVirtioBlk *blk_if = obj;
+    QVirtioDevice *dev = blk_if->vdev;
+    QVirtQueue *vq;
+    uint8_t status;
+    /* Edge case of a serial with exactly 20 characters: No NUL termination */
+    const char expected[25] = "01234567890123456789\xa5\xa5\xa5\xa5\xa5";
+    char buf[25];
+
+    vq = get_id_setup(dev, t_alloc);
+    status = get_id_request(dev, vq, buf, 25, 0xa5, t_alloc);
+    g_assert_cmpint(status, ==, 0);
+    g_assert_cmpmem(buf, 25, expected, sizeof(expected));
+
+    qvirtqueue_cleanup(blk_if->vdev->bus, vq, t_alloc);
+}
+
 static void *virtio_blk_test_setup(GString *cmd_line, void *arg)
 {
     char *tmp_path = drive_create();
@@ -802,6 +889,15 @@ static void register_virtio_blk_test(void)
     qos_add_test("nxvirtq", "virtio-blk-pci",
                       test_nonexistent_virtqueue, &opts);
     qos_add_test("hotplug", "virtio-blk-pci", pci_hotplug, &opts);
+
+    /* serial number tests */
+    opts.edge.extra_device_opts = "serial=abc";
+    qos_add_test("get_id/serial_short", "virtio-blk",
+                 get_id_serial_short, &opts);
+
+    opts.edge.extra_device_opts = "serial=01234567890123456789";
+    qos_add_test("get_id/serial_short_20_characters", "virtio-blk",
+                 get_id_serial_short_20_characters, &opts);
 }
 
 libqos_init(register_virtio_blk_test);
-- 
2.56.0

Re: [PATCH v2 2/4] virtio-blk-test: Add a basic GET_ID test case

[Stefan Hajnoczi]

On Fri, Oct 30, 2026 at 12:09:59AM +0100, Kevin Wolf wrote:
> This covers the simple common case with no surprises: A serial that is
> shorter than 20 characters and can fit in the request buffer.
> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
>  tests/qtest/virtio-blk-test.c | 96 +++++++++++++++++++++++++++++++++++
>  1 file changed, 96 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

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

[Kevin Wolf]

Commit a8686a9b, which made serial a qdev property instead of relying on
-drive options, accidentally allowed specifying serial strings of
arbitraty length while the virtio-blk protocol can only communicate 20
characters to the guest. This means that a longer serial number on the
command line is silently truncated to 20 characters from the guest
perspective.

This is obviously bad behaviour. People are specifying longer serials in
practice and guests will see something different than what was
configured. Instead of silent truncation, this should be an error.

Deprecate the silent truncation for now as a first step towards making
it an error later.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>
---
 docs/about/deprecated.rst | 13 +++++++++++++
 hw/block/virtio-blk.c     |  6 ++++++
 2 files changed, 19 insertions(+)

diff --git a/docs/about/deprecated.rst b/docs/about/deprecated.rst
index dab47b6ca38..0891bbc44de 100644
--- a/docs/about/deprecated.rst
+++ b/docs/about/deprecated.rst
@@ -362,6 +362,19 @@ the addition of volatile memory support, it is now necessary to distinguish
 between persistent and volatile memory backends.  As such, memdev is deprecated
 in favor of persistent-memdev.
 
+``-device virtio-blk,serial=more_than_20_characters`` (since 11.2)
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+The ``virtio-blk`` device has a limitation of 20 characters for the serial
+string. Accidentally, QEMU started accepting longer strings on the command line
+in version 0.15.0, but it was still silently truncated to 20 characters for
+guests.
+
+Specifying a longer serial than can be exposed to the guest is a configuration
+error and deprecated; it will become a hard error in later versions. If the
+truncation is intentional, explicitly specify the serial already in truncated
+form on the command line instead.
+
 Block device options
 ''''''''''''''''''''
 
diff --git a/hw/block/virtio-blk.c b/hw/block/virtio-blk.c
index 3f236f22d57..eeeb405127c 100644
--- a/hw/block/virtio-blk.c
+++ b/hw/block/virtio-blk.c
@@ -1849,6 +1849,12 @@ static void virtio_blk_device_realize(DeviceState *dev, Error **errp)
         return;
     }
 
+    if (conf->serial && strlen(conf->serial) > VIRTIO_BLK_ID_BYTES) {
+        warn_report("serial is longer than %d characters and will be truncated "
+                    "for the guest. This configuration is deprecated.",
+                    VIRTIO_BLK_ID_BYTES);
+    }
+
     if (!blkconf_apply_backend_options(&conf->conf,
                                        !blk_supports_write_perm(conf->conf.blk),
                                        true, errp)) {
-- 
2.56.0

[PATCH v2 4/4] virtio-blk-test: Test truncated serial

[Kevin Wolf]

Only 20 bytes are written to the passed buffer and the returned string
doesn't have a NUL terminator.

Signed-off-by: Kevin Wolf <kwolf@redhat.com>
---
 tests/qtest/virtio-blk-test.c | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)

diff --git a/tests/qtest/virtio-blk-test.c b/tests/qtest/virtio-blk-test.c
index 825ea261bed..722bd0711fa 100644
--- a/tests/qtest/virtio-blk-test.c
+++ b/tests/qtest/virtio-blk-test.c
@@ -858,6 +858,25 @@ static void get_id_serial_short_20_characters(void *obj, void *data,
     qvirtqueue_cleanup(blk_if->vdev->bus, vq, t_alloc);
 }
 
+static void get_id_serial_short_trunc(void *obj, void *data,
+                                      QGuestAllocator *t_alloc)
+{
+    QVirtioBlk *blk_if = obj;
+    QVirtioDevice *dev = blk_if->vdev;
+    QVirtQueue *vq;
+    uint8_t status;
+    /* Everything after the 20 character maximum is untouched, no '\0' */
+    const char expected[25] = "01234567890123456789\xa5\xa5\xa5\xa5\xa5";
+    char buf[25];
+
+    vq = get_id_setup(dev, t_alloc);
+    status = get_id_request(dev, vq, buf, 25, 0xa5, t_alloc);
+    g_assert_cmpint(status, ==, 0);
+    g_assert_cmpmem(buf, 25, expected, sizeof(expected));
+
+    qvirtqueue_cleanup(blk_if->vdev->bus, vq, t_alloc);
+}
+
 static void *virtio_blk_test_setup(GString *cmd_line, void *arg)
 {
     char *tmp_path = drive_create();
@@ -898,6 +917,10 @@ static void register_virtio_blk_test(void)
     opts.edge.extra_device_opts = "serial=01234567890123456789";
     qos_add_test("get_id/serial_short_20_characters", "virtio-blk",
                  get_id_serial_short_20_characters, &opts);
+
+    opts.edge.extra_device_opts = "serial=012345678901234567890123456789";
+    qos_add_test("get_id/serial_short_trunc", "virtio-blk",
+                 get_id_serial_short_trunc, &opts);
 }
 
 libqos_init(register_virtio_blk_test);
-- 
2.56.0

Re: [PATCH v2 4/4] virtio-blk-test: Test truncated serial

[Stefan Hajnoczi]

On Fri, Oct 30, 2026 at 12:10:01AM +0100, Kevin Wolf wrote:
> Only 20 bytes are written to the passed buffer and the returned string
> doesn't have a NUL terminator.
> 
> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
> ---
>  tests/qtest/virtio-blk-test.c | 23 +++++++++++++++++++++++
>  1 file changed, 23 insertions(+)

Reviewed-by: Stefan Hajnoczi <stefanha@redhat.com>

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

[Stefan Hajnoczi]

On Fri, Oct 30, 2026 at 12:09:57AM +0100, Kevin Wolf wrote:
> 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.
> 
> v2:
> - Drop truncation of qdev property for now [Stefan]
> - Add test case for exactly 20 characters [Stefan]
> - Fix missing guest_free() [Stefan]
> - Pass pattern_byte to get_id_request() instead of hardcoding it
>   [Stefan]
> 
> Kevin Wolf (4):
>   virtio-blk: Implement full NUL padding for GET_ID
>   virtio-blk-test: Add a basic GET_ID test case
>   virtio-blk: Deprecate silent truncation of serial
>   virtio-blk-test: Test truncated serial
> 
>  docs/about/deprecated.rst     |  13 ++++
>  hw/block/virtio-blk.c         |  18 +++--
>  tests/qtest/virtio-blk-test.c | 119 ++++++++++++++++++++++++++++++++++
>  3 files changed, 146 insertions(+), 4 deletions(-)
> 
> -- 
> 2.56.0
> 

Thanks, applied to my block tree:
https://gitlab.com/stefanha/qemu/commits/block

Stefan

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

[Christian Borntraeger]

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.
virtio SCSI LUN passthru has that but it is significantly slower (factors)
and that was also real feedback from that customer.



> 
> v2:
> - Drop truncation of qdev property for now [Stefan]
> - Add test case for exactly 20 characters [Stefan]
> - Fix missing guest_free() [Stefan]
> - Pass pattern_byte to get_id_request() instead of hardcoding it
>    [Stefan]
> 
> Kevin Wolf (4):
>    virtio-blk: Implement full NUL padding for GET_ID
>    virtio-blk-test: Add a basic GET_ID test case
>    virtio-blk: Deprecate silent truncation of serial
>    virtio-blk-test: Test truncated serial
> 
>   docs/about/deprecated.rst     |  13 ++++
>   hw/block/virtio-blk.c         |  18 +++--
>   tests/qtest/virtio-blk-test.c | 119 ++++++++++++++++++++++++++++++++++
>   3 files changed, 146 insertions(+), 4 deletions(-)
> 

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

[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?

> 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?

Kevin

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

[Christian Borntraeger]

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.


> 
>> 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?

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.

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

[Kevin Wolf]

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