From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44900 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1PsX1f-0000un-FQ for qemu-devel@nongnu.org; Thu, 24 Feb 2011 03:58:20 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1PsX1c-00013z-Vr for qemu-devel@nongnu.org; Thu, 24 Feb 2011 03:58:19 -0500 Received: from mx1.redhat.com ([209.132.183.28]:10926) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1PsX1c-00013e-Kd for qemu-devel@nongnu.org; Thu, 24 Feb 2011 03:58:16 -0500 Message-ID: <4D661DA2.2050102@redhat.com> Date: Thu, 24 Feb 2011 10:58:10 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <20110222170004.808373778@redhat.com> <20110222170115.710717278@redhat.com> <4D642181.4080509@codemonkey.ws> <20110222210735.GA9372@amt.cnet> <4D64266A.3060106@codemonkey.ws> <20110222230935.GA11082@amt.cnet> <4D644343.4050800@codemonkey.ws> <4D65051A.6070707@redhat.com> <20110223174917.GA4630@amt.cnet> In-Reply-To: <20110223174917.GA4630@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Jes.Sorensen@redhat.com, qemu-devel@nongnu.org On 02/23/2011 07:49 PM, Marcelo Tosatti wrote: > On Wed, Feb 23, 2011 at 03:01:14PM +0200, Avi Kivity wrote: > > On 02/23/2011 01:14 AM, Anthony Liguori wrote: > > > > > >-drive already ties into the qemuopts infrastructure and we have > > >readconfig and writeconfig. I don't think we're missing any major > > >pieces to do this in a more proper fashion. > > > > The problem with qemu config files is that it splits the > > authoritative source of where images are stored into two. Is it in > > the management tool's database or is it in qemu's config file? > > > > For the problem at hand, one solution is to make qemu stop after the > > copy, and then management can issue an additional command to > > rearrange the disk and resume the guest. A drawback here is that if > > management dies, the guest is stopped until it restarts. We also > > make management latency guest visible, even if it doesn't die at an > > inconvenient place. > > > > An alternative approach is to have the copy be performed by a new > > layered block format driver: > > > > - create a new image, type = live-copy, containing three pieces of > > information > > - source image > > - destination image > > - copy state (initially nothing is copied) > > - tell qemu switch to the new image > > - qemu starts copying, updates copy state as needed > > - copy finishes, event is emitted; reads and writes still serviced > > - management receives event, switches qemu to destination image > > - management removes live-copy image > > > > If management dies while this is happening, it can simply query the > > state of the copy. > > Similarly, if qemu dies, the copy state is persistent (could be 0/1 or > > real range of blocks). > > You don't know if a given block is uptodate or not without the dirty > bitmap. So unless you also keep track of dirty log somehow, this is > meaningless. First, you no longer need the dirty bitmap. Since all writes go through the layered block format driver, you know first-hand what is dirty and what isn't. > So a commit file as proposed indicates copy state (in 0/1 fashion). The > difference in your proposal is that such information is stored inside a > special purpose image format? > It could also store the already synced range. The difference is that the file is self contained. You could hot-unplug the image and hot-plug it later (continuing the copy with qemu-img), or live migrate it. In fact I think a qemu RAID-1 driver removes the restriction that you can't live-migrate and live-copy simultaneously. -- error compiling committee.c: too many arguments to function