Red Hat Bugzilla – Bug 1086704
Don't allow aio=native without cache=none
Last modified: 2015-09-09 05:09:49 EDT
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, so the behaviour will stay there. Still, in the common case such behaviour is surprising and management should protect the user against it by rejecting or (if at all possible on the libvirt level) warning against it. danpb suggested on IRC that libvirt doesn't have such a check yet and I should file a bug.
(In reply to Kevin Wolf from comment #0) > 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, so the behaviour will > stay there. Still, in the common case such behaviour is surprising and > management should protect the user against it by rejecting or (if at all > possible on the libvirt level) warning against it. > > danpb suggested on IRC that libvirt doesn't have such a check yet and I > should > file a bug. FYI: We have such a bug 1086502 for qemu-kvm component which caused QEMU core dumped. Best Regards, sluo
This patch seems to be enough for showing a warning and it is the solution I am in favour of: diff --git a/src/qemu/qemu_command.c b/src/qemu/qemu_command.c index 4829176..6af76ce 100644 --- a/src/qemu/qemu_command.c +++ b/src/qemu/qemu_command.c @@ -3449,6 +3449,14 @@ qemuBuildDriveStr(virConnectPtr conn, mode = qemuDiskCacheV1TypeToString(disk->cachemode); } + if (disk->iomode == VIR_DOMAIN_DISK_IO_NATIVE && + disk->cachemode != VIR_DOMAIN_DISK_CACHE_DIRECTSYNC) { + VIR_WARN(_("native I/O needs either no disk cache " + "or directsync cache mode, QEMU will fallback " + "to aio=threads")); + goto error; + } + virBufferAsprintf(&opt, ",cache=%s", mode); } else if (disk->shared && !disk->readonly) { virBufferAddLit(&opt, ",cache=off"); is a warning enough in this case or should VIR_WARN be promoted to virReportError and deny the execution of the VM?
fixed upstream by: commit 058384003db776c580d0e5a3016a6384e8eb7b92 Author: Giuseppe Scrivano <gscrivan@redhat.com> Date: Tue Jul 8 16:08:57 2014 +0200 qemu: raise an eror when using aio=native without cache=none Qemu will fallback to aio=threads when the cache mode doesn't use O_DIRECT, even if aio=native was explictly set. Closes: https://bugzilla.redhat.com/show_bug.cgi?id=1086704 Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com> Fine to close this as UPSTREAM?
No, we need to make sure this is properly tested by QA.
Test with the following package version, this bug is verified. Package version: libvirt-1.2.8-8.el7.x86_64 qemu-kvm-rhev-2.1.2-12.el7.x86_64 kernel-3.10.0-208.el7.x86_64 Testing Matrix: 1. combine option testing "io='native'" and "cache='writethrough'", then start guest. #virsh dumpxml rhel7.1 ...... <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writethrough' io='native'/> <source dev='/dev/sdc'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> ...... # virsh start rhel7.1 error: Failed to start domain rhel7.1 error: unsupported configuration: native I/O needs either no disk cache or directsync cache mode, QEMU will fallback to aio=threads 2. combine option testing "io='native'" and "cache='writeback'", then start guest. #virsh dumpxml rhel7.1 ...... <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='writeback' io='native'/> <source dev='/dev/sdc'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> ...... # virsh start rhel7.1 error: Failed to start domain rhel7.1 error: unsupported configuration: native I/O needs either no disk cache or directsync cache mode, QEMU will fallback to aio=threads 3. combine option testing "io='native'" and "cache='unsafe'", then start guest. #virsh dumpxml rhel7.1 ...... <disk type='block' device='disk'> <driver name='qemu' type='raw' cache='unsafe' io='native'/> <source dev='/dev/sdc'/> <target dev='vdb' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x09' function='0x0'/> </disk> ...... # virsh start rhel7.1 error: Failed to start domain rhel7.1 error: unsupported configuration: native I/O needs either no disk cache or directsync cache mode, QEMU will fallback to aio=threads 4. as for other cache type and io type combination testing, the guest can be started up as expected. Following is the option combination testing matrix for your reference: 4.1 "io='native'" and "cache='default'" ----> guest can be started up as expected. 4.2 "io='native'" and "cache='none'" ----> guest can be started up as expected. 4.3 "io='native'" and "cache='directsync'" ----> guest can be started up as 4.4 "io='threads'" and "cache='writethrough'" ----> guest can be started up as expected. 4.5 "io='threads'" and "cache='none'" ----> guest can be started up as expected. 4.6 "io='threads'" and "cache='directsync'" ----> guest can be started up as expected. 4.7 "io='threads'" and "cache='default'" ----> guest can be started up as expected. 4.8 "io='threads'" and "cache='writeback'" ----> guest can be started up as expected. 4.9 "io='threads'" and "cache='unsafe'" ----> guest can be started up as expected.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHSA-2015-0323.html
*** Bug 1259398 has been marked as a duplicate of this bug. ***