Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format

[Kaveh Razavi <kaveh@cs.vu.nl>]

On 08/13/2013 11:37 PM, Eric Blake wrote:
> What is the QMP counterpart for hot-plugging a disk with the cache
> attached?  Is this something that can integrate nicely with Kevin's
> planned blockdev-add for 1.7?
> 

I do not know the details of this, but as long as it has proper support
for backing files, integration should be straightforward. I can take a
look if you point me to the right path.

> Please post this as a series, with patch 1 of the series being a doc
> patch to docs/specs/qcow2.txt fully documenting this extension.  No one
> else can be expected to interoperate with your extension if you don't
> document it upstream.  I want to make sure that there are no races where
> two competing processes both open a file read-write, and where the first
> process requests to modify metadata (possibly by adding the cache
> designation header, but also by making some other modification), but
> where before that completes, the other process sees an incomplete
> picture of the metadata.  We already document that qemu-img is liable to
> misbehave, even when operating in read-only mode, on an image held
> read-write by one qemu process; and I want to see in the formal docs
> (without having to chase a link to the pdf) how you guarantee that this
> is safe.

I can repost this later on, updating the document and fixing the race.
The way we intended it, only a single qemu process at each host should
write to the cache. Once this is done, the cache should be marked as
ready. Subsequent boots on that host can reuse this read-only cache,
only if it is ready. For this, we likely need a variable in the header
extension that defines whether the cache image is ready/cold/dirty. If
the image is not ready, it should be discarded and the cache's backing
file be used instead. If the image is cold, a VM can set the variable to
dirty, start warming it, and set it back to ready on shutdown.

Kaveh