af2405e118
Because of the libvirt issue[1], there is a bug[2] that if we set cache mode whose write semantic is not O_DIRECT (.i.e unsafe, writeback or writethrough), there will be a problem with the volume drivers (.i.e nova.virt.libvirt.volume.LibvirtISCSIVolumeDriver, nova.virt.libvirt.volume.LibvirtNFSVolumeDriver and so on), which designate native io explicitly. That problem will generate a libvirt xml for the instance, whose content contains ``` ... <disk ... > <driver ... cache='unsafe/writeback/writethrough' io='native' /> </disk> ... ``` In turn, it will fail to start the instance or attach the disk. > When qemu is configured with a block device that has aio=native set, but > the cache mode doesn't use O_DIRECT (i.e. isn't cache=none/directsync or any > unnamed mode with explicit cache.direct=on), then the raw-posix block driver > for local files and block devices will silently fall back to aio=threads. > The blockdev-add interface rejects such combinations, but qemu can't > change the existing legacy interfaces that libvirt uses today. [1]: https://github.com/libvirt/libvirt/commit/058384003db776c580d0e5a3016a6384e8eb7b92 [2]: https://bugzilla.redhat.com/show_bug.cgi?id=1086704 Closes-Bug: #1841363 Change-Id: If9acc054100a6733f3659a15dd9fc2d462e84d64
15 lines
674 B
YAML
15 lines
674 B
YAML
---
|
|
fixes:
|
|
- |
|
|
Since Libvirt v.1.12.0 and the introduction of the `libvirt issue`_ ,
|
|
there is a fact that if we set cache mode whose write semantic is not
|
|
O_DIRECT (i.e. "unsafe", "writeback" or "writethrough"), there will
|
|
be a problem with the volume drivers (i.e. LibvirtISCSIVolumeDriver,
|
|
LibvirtNFSVolumeDriver and so on), which designate native io explicitly.
|
|
|
|
When the driver_cache (default is none) has been configured as neither
|
|
"none" nor "directsync", the libvirt driver will ensure the driver_io
|
|
to be "threads" to avoid an instance spawning failure.
|
|
|
|
.. _`libvirt issue`: https://bugzilla.redhat.com/show_bug.cgi?id=1086704
|