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
