KVM: Add io driver option to libvirt XML for io_uring support

[wido]

ISSUE TYPE

• Feature Idea

COMPONENT NAME

KVM

CLOUDSTACK VERSION

master

SUMMARY

ouring is a new kernel asynchronous I/O processing mechanism proposed as a much faster alternative for conventional Linux AIO. Patches were merged in Linux 5.1 and gave a promised performance boost. We decided to integrate it into QEMU to make virtualized storage devices work more efficiently. Let's take a look at how iouring works in QEMU.

Source:

• https://www.phoronix.com/scan.php?page=news_item&px=KVM-IO-uring-Passthrough-LF2020
• https://archive.fosdem.org/2020/schedule/event/vai_io_uring_in_qemu/

By using io_uring with Qemu we can see a massive I/O performance improvement within Virtual Machines running from Local and/or NFS storage.

In order to use this we need:

• Qemu >= 5.0
• Libvirt >= 6.3.0

We then need to add this to the XML definition for libvirt which would then look like:

    <disk type='file' device='disk'>
      <driver name='qemu' type='qcow2' cache='writeback' discard='unmap' io='io_uring'/>
      <source file='/var/lib/libvirt/images/a0f677c6-b065-4795-b468-2b5974496c75'/>
      <backingStore/>
      <target dev='sda' bus='scsi'/>
      <serial>a0f677c6b0654795b468</serial>
      <alias name='scsi0-0-0-0'/>
      <address type='drive' controller='0' bus='0' target='0' unit='0'/>
    </disk>

With io_uring I/O performance can improve drastically and reach near bare-metal performance.

Currently there is no Qemu version in a stable Ubuntu nor CentOS release, but we can already merge this in master so that when this is released we can use it.

[DaanHoogland]

looks like a minor change @wido , but will qemu/libvirt trip over the additional attribute if it is not yet supported, I.E. do we need an operator the set a switch and be intelligent about it? and can we query this per host (in case of a slow transition of a big env)?

[wido]

looks like a minor change @wido , but will qemu/libvirt trip over the additional attribute if it is not yet supported, I.E. do we need an operator the set a switch and be intelligent about it? and can we query this per host (in case of a slow transition of a big env)?

It is very small indeed. @GabrielBrascher already started to work on this. Based on the Qemu and Libvirt version this is added or not.

In this case we can query this per host.

[GabrielBrascher]

@DaanHoogland to give some taste of the draft here follows the first commit CLDIN@c7c3dd3
⚠️warning: work-in-progress 🙂

As @wido mentioned, we can check the libvirt/qemu versions via the cloudstack-agent service that is running on the KVM node.

Example:

if(_hypervisorLibvirtVersion >= 6030000 && _hypervisorQemuVersion >= 5000000) {
    disk.setIoDriver(DiskDef.IoDriver.IOURING);
}

[DaanHoogland]

looks good so far, but my question about application architecture is only now getting clear to myself: will the knowledge be in the orchestrations layer, or will it be purely a provisioning (agent side) matter? I.E. do we want the opreator to be able to "sell" this to the users?
thanks guys

[wido]

looks good so far, but my question about application architecture is only now getting clear to myself: will the knowledge be in the orchestrations layer, or will it be purely a provisioning (agent side) matter? I.E. do we want the opreator to be able to "sell" this to the users?
thanks guys

This will be in the agent side (provisioning). It will be turned on if supported. This then makes sure the VM gets more I/O performance.