From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:59063) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qe0a8-00035z-R4 for qemu-devel@nongnu.org; Tue, 05 Jul 2011 04:02:10 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Qe0a5-0001BT-2V for qemu-devel@nongnu.org; Tue, 05 Jul 2011 04:02:08 -0400 Received: from mx1.redhat.com ([209.132.183.28]:13391) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Qe0a4-0001B1-Ih for qemu-devel@nongnu.org; Tue, 05 Jul 2011 04:02:04 -0400 Message-ID: <4E12C4F5.9000100@redhat.com> Date: Tue, 05 Jul 2011 11:01:57 +0300 From: Dor Laor MIME-Version: 1.0 References: <20110628194106.GA17443@amt.cnet> <4E0ADAE0.6040204@redhat.com> <20110629154134.GA6631@amt.cnet> <20110630143620.GA4366@amt.cnet> <4E0C8D90.8050305@redhat.com> <20110630183829.GA8752@amt.cnet> In-Reply-To: <20110630183829.GA8752@amt.cnet> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] KVM call agenda for June 28 Reply-To: dlaor@redhat.com List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Marcelo Tosatti Cc: Kevin Wolf , Chris Wright , KVM devel mailing list , quintela@redhat.com, Stefan Hajnoczi , qemu-devel@nongnu.org, Avi Kivity , jes sorensen I tried to re-arrange all of the requirements and use cases using this wiki page: http://wiki.qemu.org/Features/LiveBlockMigration It would be the best to agree upon the most interesting use cases (while we make sure we cover future ones) and agree to them. The next step is to set the interface for all the various verbs since the implementation seems to be converging. Cheers, Dor On 06/30/2011 09:38 PM, Marcelo Tosatti wrote: > On Thu, Jun 30, 2011 at 04:52:00PM +0200, Kevin Wolf wrote: >> Am 30.06.2011 16:36, schrieb Marcelo Tosatti: >>>> 4. Live block copy API and high-level control - the main code that >>>> adds the live block copy feature. Existing patches by Marcelo, can be >>>> restructured to use common core by Marcelo. >>> >>> Can use your proposed block_stream interface, with a "block_switch" >>> command on top, so: >>> >>> 1) management creates copy.img with backing file current.img, allows >>> access >>> 2) management issues "block_switch dev copy.img" >>> 3) management issues "block_stream dev base" >> >> Isn't this block_switch command the same as the existing snapshot_blkdev? > > Yep. > >>> Thought of implementing "block_stream" command by reopening device with >>> >>> blkstream:imagename.img >>> >>> Then: >>> >>> AIO_READ: >>> - for each cluster in request: >>> - if allocated-or-in-final-base, read. >>> - check write queue, if present wait on it, if not, add "copy" >>> entry to write queue. >>> - issue cluster sized read from source. >>> - on completion: >>> - copy data to original read buffer, complete it. >>> - if not cancelled, write cluster to destination. >>> >>> AIO_WRITE >>> for each cluster in request: >>> - check write queue, cancel/wait for "copy" entry. >>> - add "guest" entry to write queue. >>> - issue write to destination. >>> - on completion: >>> - remove write queue entry. >>> >>> >>> With the 0...END background read, once it completes write final base >>> file for image. >>> >>> So block_stream/block_stream_cancel/block_stream_status commands, the >>> background read and the rebase -u update can be separate from the block >>> driver. >> >> The way how it works looks good to me, I'm just not entirely sure about >> the right place to implement it. I think request queueing and copy on >> read could be useful outside blkstream, too. > > They could be lifted later, when there are other users. > > -- > To unsubscribe from this list: send the line "unsubscribe kvm" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html