From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:59566) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9sf8-0008G0-Jk for qemu-devel@nongnu.org; Thu, 15 Aug 2013 04:12:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V9sf0-0002gm-6H for qemu-devel@nongnu.org; Thu, 15 Aug 2013 04:12:06 -0400 Received: from mail-ea0-x234.google.com ([2a00:1450:4013:c01::234]:34510) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V9sez-0002gf-W8 for qemu-devel@nongnu.org; Thu, 15 Aug 2013 04:11:58 -0400 Received: by mail-ea0-f180.google.com with SMTP id h10so201894eaj.25 for ; Thu, 15 Aug 2013 01:11:57 -0700 (PDT) Date: Thu, 15 Aug 2013 10:11:54 +0200 From: Stefan Hajnoczi Message-ID: <20130815081154.GD22521@stefanha-thinkpad.redhat.com> References: <1376413436-5424-1-git-send-email-kaveh@cs.vu.nl> <00D703C3BB04779367573E57@nimrod.local> <520B6D29.10507@cs.vu.nl> <74C74303-33D3-4E60-B999-5F96AEEFEB6F@alex.org.uk> <520B896E.8050704@cs.vu.nl> <520B937D.6060105@cs.vu.nl> <20130814153216.GN4583@dhcp-200-207.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130814153216.GN4583@dhcp-200-207.str.redhat.com> Subject: Re: [Qemu-devel] [PATCH] Introduce cache images for the QCOW2 format List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alex Bligh , Kaveh Razavi , qemu-devel@nongnu.org, Stefan Hajnoczi 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