Anthony Liguori <aligu...@us.ibm.com> wrote: > On 11/14/2011 07:11 AM, Juan Quintela wrote: >> >>> diff --git a/cpus.c b/cpus.c >>> index 82530c4..ae5ec99 100644 >>> --- a/cpus.c >>> +++ b/cpus.c >>> @@ -398,6 +398,7 @@ static void do_vm_stop(RunState state) >>> vm_state_notify(0, state); >>> qemu_aio_flush(); >>> bdrv_flush_all(); >>> + bdrv_invalidate_cache_all(); >>> monitor_protocol_event(QEVENT_STOP, NULL); >>> } >> >> This is too much. Reopening all qcow2 images each time that we stop the >> vm looks excesive, no? > > This general code came in via: > > http://mid.gmane.org/cover.1290613959.git....@redhat.com > > That series made migration stable after issuing a stop operation. I > believe the justification was for debugging purposes or something like > that. > > At any rate, invalidating the cache is part of what's required to make > things stable. If you look at something like cache=unsafe, the only > way the metadata will get flushed if via a bdrv_close since bdrv_flush > is a nop. > > So this is needed as long as we care about supporting this use-case.
Then we need a "proper" qcow2 invalidate call. Doing in qemu toplevel: (qemu)stop And now all your qcow2 block devices are closed, or perhaps failing to re-open() looks too much to me (TM). Kevin? Later, Juan.