[libvirt-users] Libvirt behavior when mixing io=native and cache=writeback

Hi all, I write about libvirt inconsistent behavior when mixing io=native and cache=writeback. This post can be regarded as an extension, or clarification request, of BZ 1086704 (https://bugzilla.redhat.com/show_bug.cgi?id=1086704) On a fully upgraded CentOS6 x86-64 machine, starting a guest with io=native and cache=writeback is permitted: no errors are raised and the VM (qemu, really) silently use "io=threads" instead. A warning should be raised, but I find reasonable that the VM is permitted to run. On a fully upgraded CentOS7 x86-64 machine, starting a guest with io=native and cache=writeback is *not* permitted: an error is raised and the guest is not started. While it is absolutely OK to alert the user about the configuration error, I feel the VM should be started as on CentOS6. Anyway, this is not a big problem when dealing with a single host. A more concerning behavior is that when trying to migrate a guest from the very first CentOS6 machine, which starts and runs such a guest with io=native and cache=writeback without problems, to a CentOS7 host, live migration aborts with an error: [root@source] virsh migrate Totem --live --copy-storage-all --persistent --verbose --unsafe qemu+ssh://root@172.31.255.11/system error: unsupported configuration: native I/O needs either no disk cache or directsync cache mode, QEMU will fallback to aio=threads This error persists even if the VM config file is changed to use "io=threads". Of course, the running image continue to have "io=native" on its parameters list, but it does not really honor the "io=native" directive, so I find strange that live migration can not proceed. I think it is very reasonable to raise an error, but such error should not block the live migration process. In short: there is some method to live migrate a running VM configured with "io=native" (but which is really using "io=threads" internally) and "cache=writeback"? Thanks. -- Danti Gionatan Supporto Tecnico Assyoma S.r.l. - www.assyoma.it email: g.danti(a)assyoma.it - info(a)assyoma.it GPG public key ID: FF5F32A8