qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Stefan Hajnoczi
Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format
Date: Thu, 15 Aug 2013 10:11:54 +0200
User-agent: Mutt/1.5.21 (2010-09-15)

On Wed, Aug 14, 2013 at 05:32:16PM +0200, Kevin Wolf wrote:
> Am 14.08.2013 um 16:26 hat Kaveh Razavi geschrieben:
> > On 08/14/2013 03:50 PM, Alex Bligh wrote:
> > > Assuming the cache quota is not exhausted, how do you know how that
> > > a VM has finished 'creating' the cache? At any point it might
> > > read a bit more from the backing image.
> > 
> > I was assuming on shutdown.
> 
> Wait, so you're not really changing the cache while it's used, but you
> only create it once and then use it like a regular backing file?  If so,
> the only thing we need to talk about is the creation, because there's no
> difference for using it.
> 
> Creation can use the existing copy-on-read functionality, and the only
> thing you need additionally is a way to turn copy-on-read off at the
> right point.
> 
> Or do I misunderstand what you're doing?

Yes, it seems we're talking about placing an intermediate backing file
on the host:

 /nfs/template.qcow2 <- /local/cache.qcow2 <- /local/vm001.qcow2

On first boot the image runs in "record" mode which populates the cache
via copy-on-read.

Once "record" mode is disabled the cache image can be shared with other
VMs on the host.  They all open it read-only and no longer modify the
cache.

At that point you have a normal qcow2 backing file chain:

 /nfs/template.qcow2 <- /local/cache.qcow2 <- /local/vm001.qcow2
                                           <- /local/vm002.qcow2

With this approach you don't need a qemu-nbd process that arbitrates
writes to the cache.qcow2 image file.  The disadvantage is that it only
caches the "record" mode read requests and does not adapt to changes if
the workload begins reading other data.  Also, it requires more
complicated management tools to handle the "record"/"playback" states of
the cache:

1. Launching vm002 while vm001 is still recording the cache.  (Bypass
   the cache temporarily for vm002.)
2. Switching the cache from "record" to "playback" after vm001 has
   finished its first run.
3. Switching vm002 to use the cache once it transitions to "playback"
   mode.

Stefan



reply via email to

[Prev in Thread] Current Thread [Next in Thread]