Description of problem:
-----------------------------------------
Cisco has requested the following change around the previous outcome of the BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1175440. The resulting solution was to change nova.conf "disk_cachemodes=network=writeback" which did not propagate the io policy in libvirt.xml, putting forth the argument that the VM performance is not optimized.
Additional research leads to the accepted blueprint for mitaka m3 release:
-----------------------------------------
Libvirt and qemu provide two different modes for asynchronous IO (AIO), “native” and “threads”. Right now nova always uses the default thread mode. Depending on the disk type that is used for backing guest disks, it can be beneficial to use the native IO mode instead which appears to be related to Cisco's request.
Upstream Blueprints:
Libvirt: AIO mode for disk devices
-----------------------------------------
https://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/libvirt-aio-mode.html#libvirt-aio-mode-for-disk-devices
bp/libvirt-aio-mode
-----------------------------------------
https://review.openstack.org/#/q/topic:bp/libvirt-aio-mode,n,z
Version-Release number of selected component (if applicable):
-----------------------------------------
All current versions of nova
How reproducible:
-----------------------------------------
100%
Steps to Reproduce:
------------------------------------------
1. Set "disk_cachemodes=network=writeback" in nova.conf
2. check libvirt.xml policy to verify io="threads" are enabled not aio="native"
Actual results:
-----------------------------------------
When "disk_cachemodes=network=writeback" is set in nova.conf, the libvirt.xml io policy is set to io="threads".
Expected results:
-----------------------------------------
When "disk_cachemodes=network=writeback" is set in nova.conf, the libvirt.xml io policy is set to aio="native".
Additional info:
-----------------------------------------
https://bugzilla.redhat.com/show_bug.cgi?id=1175440#c14https://access.redhat.com/support/cases/#/case/01665252