[Qemu-devel] Re: [PATCH 1/3] block: allow migration to work with image files

[Kevin Wolf <kwolf@redhat.com>]

Am 11.09.2010 16:04, schrieb Anthony Liguori:
> Image files have two types of data: immutable data that describes things like
> image size, backing files, etc. and mutable data that includes offset and
> reference count tables.
> 
> Today, image formats aggressively cache mutable data to improve performance.  In
> some cases, this happens before a guest even starts.  When dealing with live
> migration, since a file is open on two machines, the caching of meta data can
> lead to data corruption.
> 
> This patch addresses this by introducing a mechanism to invalidate any cached
> mutable data a block driver may have which is then used by the live migration
> code.
> 
> NB, this still requires coherent shared storage.  Addressing migration without
> coherent shared storage (i.e. NFS) requires additional work.
> 
> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
> 
> diff --git a/block.c b/block.c
> index ebbc376..cd2ee31 100644
> --- a/block.c
> +++ b/block.c
> @@ -1453,6 +1453,22 @@ const char *bdrv_get_device_name(BlockDriverState *bs)
>      return bs->device_name;
>  }
>  
> +void bdrv_invalidate_cache(BlockDriverState *bs)
> +{
> +    if (bs->drv && bs->drv->bdrv_invalidate_cache) {
> +        bs->drv->bdrv_invalidate_cache(bs);
> +    }
> +}

There is a simple generic implementation:

drv = bs->drv;
drv->close(bs);
drv->open(bs, bs->open_flags);

Note that this only reopens e.g. the qcow2 layer, but not the image
file, which is bs->file.

This works for all simple case, that is, one format on top of one or
more protocols, where the protocols don't need invalidation. I think
this includes everything that is possible today. With -blockdev we might
need to revise this to include the lower layers, too. (But only
sometimes, because we don't want to reopen the file)

Kevin