From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=59146 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OszW5-0008V8-Ra for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:51:26 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OszW0-0005uR-5O for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:51:21 -0400 Received: from e8.ny.us.ibm.com ([32.97.182.138]:54524) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OszW0-0005uM-07 for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:51:16 -0400 Received: from d01relay02.pok.ibm.com (d01relay02.pok.ibm.com [9.56.227.234]) by e8.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o87EWtqJ006216 for ; Tue, 7 Sep 2010 10:32:55 -0400 Received: from d03av05.boulder.ibm.com (d03av05.boulder.ibm.com [9.17.195.85]) by d01relay02.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o87EpFDU432706 for ; Tue, 7 Sep 2010 10:51:15 -0400 Received: from d03av05.boulder.ibm.com (loopback [127.0.0.1]) by d03av05.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o87EpElI018166 for ; Tue, 7 Sep 2010 08:51:14 -0600 Message-ID: <4C865160.5030600@linux.vnet.ibm.com> Date: Tue, 07 Sep 2010 09:51:12 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] QEMU interfaces for image streaming and post-copy block migration References: <4C864118.7070206@linux.vnet.ibm.com> In-Reply-To: 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: Stefan Hajnoczi Cc: "libvir-list@redhat.com" , qemu-devel , Stefan Hajnoczi On 09/07/2010 09:33 AM, Stefan Hajnoczi wrote: > On Tue, Sep 7, 2010 at 2:41 PM, Anthony Liguori > wrote: > >> The interface for copy-on-read is just an option within qemu-img create. >> Streaming, on the other hand, requires a bit more thought. Today, I have a >> monitor command that does the following: >> >> stream >> >> Which will try to stream the minimal amount of data for a single I/O >> operation and then return how many sectors were successfully streamed. >> >> The idea about how to drive this interface is a loop like: >> >> offset = 0; >> while offset< image_size: >> wait_for_idle_time() >> count = stream(device, offset) >> offset += count >> >> Obviously, the "wait_for_idle_time()" requires wide system awareness. The >> thing I'm not sure about is 1) would libvirt want to expose a similar stream >> interface and let management software determine idle time 2) attempt to >> detect idle time on it's own and provide a higher level interface. If (2), >> the question then becomes whether we should try to do this within qemu and >> provide libvirt a higher level interface. >> > A self-tuning solution is attractive because it reduces the need for > other components (management stack) or the user to get involved. In > this case self-tuning should be possible. We need to detect periods > of I/O inactivity, for example tracking the number of in-flight > requests and then setting a grace timer when it reaches zero. When > the grace timer expires, we start streaming until the guest initiates > I/O again. > That detects idle I/O within a single QEMU guest, but you might have another guest running that's I/O bound which means that from an overall system throughput perspective, you really don't want to stream. I think libvirt might be able to do a better job here by looking at overall system I/O usage. But I'm not sure hence this RFC :-) Regards, Anthony Liguori > Stefan >