 | ||
| VirtIO disk drives | ||
|---|---|---|
| Prev | About Kernel-based Virtual Machine (KVM) technology | Next |
VirtIO is an abstraction layer for paravirtualized hypervisors in Kernel-based Virtual Machine (VM) technology. Unlike full virtualization, VirtIO requires special paravirtualized drivers running in each VM guest. VirtIO provides support for many devices including network devices and block (disk) devices. Using VirtIO to export block devices to a host allows files, VxVM volumes, DMP meta-nodes, SCSI devices or any other type of block device residing on host to be presented to the VM guest. When SCSI devices are presented to a VM guest using VirtIO, in addition to simple reads and writes, SCSI commands such as SCSI inquiry commands can be performed allowing VxVM in the guest to perform deep device discovery. Running VxVM and DMP in the host and the VM guest provides for consistent naming of SCSI devices from the array, to the host through to the VM guest.
Veritas InfoScale Solutions 7.3 supports VirtIO SCSI devices and VirtIO block devices with Linux KVM. virtio-scsi is a new virtual SCSI HBA interface. It is the foundation of an alternative storage implementation for virtual machines, replacing virtio-blk on Red Hat Enterprise Linux (RHEL) with improved scalability and providing standard SCSI command set support.
VirtIO features:
Dynamically adding devices:
VirtIO disk devices can be both added and removed from a running VM guest dynamically, without the need of a reboot.
VirtIO limitations:
Disk caching:
When disks are exported to the VM guest with the cache enabled, the VxVM configuration changes may get cached on the KVM host and not be applied to the disks. When disks are shared between more than one VM guest, such a configuration change is not visble from other VM guest systems than the one which made the change. To avoid potential configuration conflict, caching the host must be disabled (cache=no) while exporting the disks.
SCSI Commands:
SCSI devices that are presented as VirtIO devices to a VM guest support a limited subset of the SCSI command set. The KVM hypervisor blocks the restricted commands.
PGR SCSI-3 Reservations:
PGR SCSI-3 reservations are not supported on VirtIO block devices. To use SCSI-3 PR operations inside the KVM guest operating system, Veritas recommends that you use virtio-scsi to export SCSI devices to the guest. This limitation is applicable to releases prior to RHEL 6.4.
DMP Fast Recovery with SCSI devices:
DMP Fast Recovery bypasses the normal VirtIO read/write mechanism, performing SCSI commands directly against the device. If DMP Fast Recovery is used within the VM guest, caching in the host must be disabled (cache=none), to avoid data integrity issues.
Thin Reclamation:
Thin reclamation is not supported on VirtIO devices. The 'WRITE-SAME' command is blocked by the hypervisor. This limitation may be removed in future releases of Linux.
Resizing devices:
Linux does not support online disk resizing of VirtIO devices. To re-size a VirtIO device the VM guest must be fully shut down and re-started. Support for online re-sizing of block devices is under evaluation for Linux.
Maximum number of devices:
virtio-blk currently has a per-guest limitation of 32 devices. This device limitation includes all VirtIO devices, such as network interfaces and block devices. The device limitation is a result of the current VirtIO implementation where each device acts as a separate PCI device. virtio-scsi solves this limitation by multiplexing numerous storage devices on a single controller. Each device on a virtio-scsi controller is represented as a logical unit, or LUN. The LUNs are grouped into targets. The device limit per target is much larger; each device can have a maximum of 256 targets per controller and 16,384 logical units per target. You can use virtio-scsi instead of virtio-blk to use more than 32(28) disk devices inside the KVM guest.
VxFS:
In a KVM environment under heavy I/O load, data corruption may occur on VxFS file systems created on LUNs attached as VirtIO block devices. Please refer Red Hat Support Case #00945974 for more details: