[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [qemu-web PATCH v2] Add virtio-blk and virtio-scsi configuration pos

From: Thomas Huth
Subject: Re: [qemu-web PATCH v2] Add virtio-blk and virtio-scsi configuration post
Date: Wed, 6 Jan 2021 15:04:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.4.0

On 05/01/2021 11.49, Stefan Hajnoczi wrote:
The second post in the storage series covers virtio-blk and virtio-scsi.
It compares the two and offers recommendations that users and tools
using QEMU can use as a starting point. Graphs are included comparing
the performance of various options.

Signed-off-by: Stefan Hajnoczi <stefanha@redhat.com>
  * Mention default storage controllers for non-x86 [danpb]
  * Remove statement about read-only ISO virtio-blk devices, both Rich
    Jones and Daniel Berrange commented about this at different times so
    I decided to drop it completely [danpb]
  * Clarify PCI slot limits and multi-function discussion for virtio-blk
  * Mention multiple virtio-scsi devices for NUMA tuning and that
    emulated LUNs can be HDDs or CD-ROMs [danpb]
  ...020-12-17-virtio-blk-scsi-configuration.md | 115 ++++++++++++++++++
  screenshots/2020-09-15-scsi-devices.svg       |   1 +
  screenshots/2020-09-15-virtio-blk-vs-scsi.svg |   1 +
  3 files changed, 117 insertions(+)
  create mode 100644 _posts/2020-12-17-virtio-blk-scsi-configuration.md
  create mode 100644 screenshots/2020-09-15-scsi-devices.svg
  create mode 100644 screenshots/2020-09-15-virtio-blk-vs-scsi.svg

diff --git a/_posts/2020-12-17-virtio-blk-scsi-configuration.md 
new file mode 100644
index 0000000..b4361f5
--- /dev/null
+++ b/_posts/2020-12-17-virtio-blk-scsi-configuration.md
@@ -0,0 +1,115 @@
+layout: post
+title:  "Configuring virtio-blk and virtio-scsi Devices"
+date:   2021-01-05 07:00:00 +0000
+author: Stefan Hajnoczi and Sergio Lopez
+categories: [storage]
+The [previous article](https://www.qemu.org/2020/09/14/qemu-storage-overview/)
+in this series introduced QEMU storage concepts. Now we move on to look at the
+two most popular emulated storage controllers for virtualization: virtio-blk
+and virtio-scsi.
+This post provides recommendations for configuring virtio-blk and virtio-scsi
+and how to choose between the two devices. The recommendations provide good
+performance in a wide range of use cases and are suitable as default settings
+in tools that use QEMU.
+## Virtio storage devices
+### Key points
+* Prefer virtio storage devices over other emulated storage controllers.
+* Use the latest virtio drivers.
+Virtio devices are recommended over other emulated storage controllers as they
+are generally the most performant and fully-featured storage controllers in
+Unlike emulations of hardware storage controllers, virtio-blk and virtio-scsi
+are specifically designed and optimized for virtualization. The details of how
+they work are published for driver and device implementors in the [VIRTIO
+Virtio drivers are available for both Linux and Windows virtual machines.

Maybe mention "and other operating systems" as well? I assume virtio drivers are also available for the various BSDs etc.

+Installing the latest version is recommended for the latest bug fixes and
+performance enhancements.
+If virtio drivers are not available, the AHCI (SATA) device is widely supported
+by modern x86 operating systems and can be used as a fallback. On non-x86
+guests the default storage controller can be used as a fallback.
+## Comparing virtio-blk and virtio-scsi
+### Key points
+* Prefer virtio-scsi for attaching more than 28 disks or for full SCSI support.

I'd rather say "lots of devices" here instead of "28", since 28 needs an explanation (which you give below).

+* Prefer virtio-blk in performance-critical use cases.

Maybe move the virtio-blk bullet above the virtio-scsi bullet, so that the two virtio-scsi bullets are listed next to each other? And it's also the order that you use below.

+* With virtio-scsi, use scsi-block for SCSI passthrough and otherwise use 
+Two virtio storage controllers are available: virtio-blk and virtio-scsi.
+### virtio-blk
+The virtio-blk device presents a block device to the virtual machine. Each
+virtio-blk device appears as a disk inside the guest. virtio-blk was available
+before virtio-scsi and is the most widely deployed virtio storage controller.
+The virtio-blk device offers high performance thanks to a thin software stack
+and is therefore a good choice when performance is a priority.

I'd maybe add some more words here, saying that virtio-blk is really simple, just read and write, and that other features might not be supported (like ejecting CD devices). Maybe also add a comment that it took a long time to add an additional command like TRIM to the device?

+Applications that send SCSI commands are better served by the virtio-scsi
+device, which has full SCSI support. SCSI passthrough was removed from the
+Linux virtio-blk driver in v5.6 in favor of using virtio-scsi.

Since "passthrough" sounds like a passthrough of real hardware devices, I'd maybe rather say something like: The original virtio-blk devices also included the possibility to handle SCSI commands, but this features was removed from the Linux driver in v5.6 in favor of using virtio-scsi (and is also not available for modern virtio-1.0 devices anymore).

+Virtual machines that require access to many disks can hit limits based on
+availability of PCI slots, which are under contention with other devices
+exposed to the guest, such as NICs. For example a typical i440fx machine type
+default configuration allows for about 28 disks. It is possible to use
+multi-function devices to pack multiple virtio-blk devies into a single PCI
+slot at the cost of losing hotplug support, or additional PCI busses can be
+defined. Generally though it is simpler to use a single virtio-scsi PCI adapter
+### virtio-scsi
+The virtio-scsi device presents a SCSI Host Bus Adapter to the virtual machine.
+SCSI offers a richer command set than virtio-blk and supports more use cases.
+Each device supports up to 16,383 LUNs (disks) per target and up to 255
+targets. This allows a single virtio-scsi device to handle all disks in a
+virtual machine, although defining more virtio-scsi devices makes it possible
+to tune for NUMA topology as we will see in a later blog post.
+Emulated LUNs can be exposed as hard disk drives or CD-ROMs. Physical SCSI
+devices can be passed through into the virtual machine, including CD-ROM
+drives, tapes, and other devices besides hard disk drives.
+Clustering software that uses SCSI Persistent Reservations is supported by 
virtio-scsi, but not by virtio-blk.
+Performance of virtio-scsi may be lower than virtio-blk due to a thicker 
software stack, but in many use cases, this is not a significant factor. The 
following graph compares 4KB random read performance at various queue depths:
+![Comparing virtio-blk and virtio-scsi 
+### virtio-scsi configuration
+The following SCSI devices are available with virtio-scsi:
+|Device|SCSI Passthrough|Performance|
+The scsi-hd device is suitable for disk image files and host block devices
+when SCSI passthrough is not required.
+The scsi-block device offers SCSI passthrough and is preferred over
+scsi-generic due to higher performance.
+The following graph compares the sequential I/O performance of these devices
+using virtio-scsi with an iothread:
+![Comparing scsi-hd, scsi-block, and scsi-generic 
+## Conclusion
+The virtio-blk and virtio-scsi offer a choice between a single block device and
+a full-fledged SCSI Host Bus Adapter. Virtualized guests typically use one or
+both of them depending on functional and performance requirements. This post
+compared the two and offered recommendations on how to choose between them.
+The next post in this series will discuss the iothreads feature that both
+virtio-blk and virtio-scsi support for increased performance.

Do you maybe also want to give examples for the QEMU command line showing how virtio-blk and virtio-scsi can be used there?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]