Avi Kivity <a...@redhat.com> wrote: > block.c says: > >> /* >> * Yes, BDRV_O_NOCACHE aka O_DIRECT means we have to present a >> * write cache to the guest. We do need the fdatasync to flush >> * out transactions for block allocations, and we maybe have a >> * volatile write cache in our backing device to deal with. >> */ >> if (flags & (BDRV_O_CACHE_WB|BDRV_O_NOCACHE)) >> bs->enable_write_cache = 1; > > This means that if I start a guest with cache=writethrough and then > restart (or live migrate) it with cache=none, then the guest will see > a change, even though the user only changed the drive's backing, not > something guest visible. In the case of live migration, the guest > will not even notice the change and we may be at risk of data loss. > > For 0.13 I propose setting enable_write_cache to true unconditionally. > For 0.12 the question is more difficult, since we'll be changing the > guest ABI. Given that guests are unlikely not to be able to cope with > write caches, and that the alternative is data loss, I believe that's > also the right solution there.
For RHEL I setted with adding enable_write_cache to the migration state. As you state, that value is guest visible. I can update that patches to qemu. When I migrated from an old version, I just set that value to 0. What do you think? Later, Juan.