vdev virtio-blk

Synopsis:

vdev virtio-blk options

Options:

delayed seconds|forever

Delay opening the host device until it is first referenced by the guest.

If the device isn't found in the host, keep trying to find the device for the number of seconds specified by seconds before timing out (e.g., delayed 5). If seconds is set to 0 (i.e., delayed 0), try only once to find the device. If the argument is set to forever (i.e., delayed forever), never time out and just keep trying to find the device.

dio disable|enable|read

Configure the use of Direct I/O when processing the guest's requests. The default setting is disable, meaning Direct I/O is not used by default. The enable setting activates it for both read and write requests. The read setting activates it only for read requests, while write requests are processed with an _IO_WRITE message. With this last setting, which is known as Mixed Mode I/O, the back-end io-blk block cache gets used as a writeback cache.

If a Direct I/O access fails at any point (either because it's not supported by the back-end driver or for any other reason), the device will permanently switch back to using _IO_READ and _IO_WRITE messages.

hostdev [<]host_filename

Use the specified host file to store the contents of the device.

A < symbol in front of host_filename indicates that device contents will be enforced as read-only (e.g., hostdev </dev/hd0 will make /dev/hd0 read-only to the guest). With no such symbol, the default read/write access is granted to the guest.

These semantics mean the hostdev option for vdev virtio-blk is different than the option with the same name for other vdevs. The < symbol doesn't specify the input source and the > symbol to specify output isn't supported.

intr intr

Signal intr for device interrupts. Not required when the vdev appears as a PCI device.

legacy

Provide the VIRTIO legacy interface (0.9.5) rather than the 1.0 or later standard versions.

loc addr

Set the base address of the device registers to addr. Not required if the vdev appears as a PCI device.

threads number

Set the number of threads for processing requests. This number must be at most 32, and will be truncated to the maximum that the back-end device actually supports if the device has a thread limit smaller than 32.

By default, only one thread is created. Having multiple threads process requests issued by the guest can improve performance for the device. Also, the threads option setting affects the number of virtqueues that get created. Having multiple virtqueues can also boost performance. For more information, refer to Multiqueue support below.

Note:

For better performance, we recommend using a number of threads that is based on the configuration of your hypervisor host system. If the system is single-core, use just one thread. If it's quad-core, use between two and four threads for optimal performance.

For the system to actually benefit from having multiple threads in the VIRTIO device, the driver in the guest must allow requests to be processed asynchronously, and the back-end driver and the back-end device in the host must not serialize the requests.

For a list of options available to all vdevs, see Common vdev options at the beginning of this chapter.

Description:

ARM and x86. The virtio-blk vdev provides an interface for block devices (e.g., SATA drives). Normally this device appears as a PCI device, but if you specify the loc and intr options, the guest will see it as a memory-mapped I/O device at the specified location.

For virtio-blk, packed virtqueues and multiqueue are enabled if the guest supports them. Information about this second feature is given just below.

Multiqueue support

If the virtio-blk vdev is given a threads option setting greater than one (1), during startup, the vdev advertises its support for the multiqueue feature, which allows a guest to control the mapping of the request-processing threads to virtqueues. If the guest driver then requests the use of multiqueue, the number of virtqueues created is the lesser of the threads option setting and the number of vCPUs created in the VM (which is the number of cpu options specified in the configuration file). Creating multiple virtqueues can improve performance when the guest has a heavy I/O load.

If the guest driver does not request multiqueue usage, only one virtqueue is created and all the threads operate on this virtqueue. This setup can still provide better performance that a vdev with just one thread but might not achieve the same performance as when multiple virtqueues are used.