From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43626 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OszCl-0004s2-Ct for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:31:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OszCg-0002md-P1 for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:31:23 -0400 Received: from e37.co.us.ibm.com ([32.97.110.158]:50106) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OszCg-0002mP-7G for qemu-devel@nongnu.org; Tue, 07 Sep 2010 10:31:18 -0400 Received: from d03relay03.boulder.ibm.com (d03relay03.boulder.ibm.com [9.17.195.228]) by e37.co.us.ibm.com (8.14.4/8.13.1) with ESMTP id o87ETDu5028788 for ; Tue, 7 Sep 2010 08:29:13 -0600 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d03relay03.boulder.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o87EVBHY189556 for ; Tue, 7 Sep 2010 08:31:13 -0600 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o87EVAJa032185 for ; Tue, 7 Sep 2010 08:31:11 -0600 Message-ID: <4C864CAD.1060706@linux.vnet.ibm.com> Date: Tue, 07 Sep 2010 09:31:09 -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> <33283952-3433-4996-8851-6C14CE342D02@suse.de> In-Reply-To: <33283952-3433-4996-8851-6C14CE342D02@suse.de> 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: Alexander Graf Cc: "libvir-list@redhat.com" , qemu-devel , Stefan Hajnoczi On 09/07/2010 09:01 AM, Alexander Graf wrote: > I'm torn here too. Why not expose both? Have a qemu internal daemon available that gets a sleep time as parameter and an external "pull sectors" command. We'll see which one is more useful, but I don't think it's too much code to justify only having one of the two. And the internal daemon could be started using a command line parameter, which helps non-managed users. > Let me turn it around and ask, how would libvirt do this? Would they just use a sleep time parameter and just make use of our command or would they do something more clever and attempt to detect system idle? Could we just do that in qemu? Or would they punt to the end user? >> A related topic is block migration. Today we support pre-copy migration which means we transfer the block device and then do a live migration. Another approach is to do a live migration, and on the source, run a block server using image streaming on the destination to move the device. >> >> With QED, to implement this one would: >> >> 1) launch qemu-nbd on the source while the guest is running >> 2) create a qed file on the destination with copy-on-read enabled and a backing file using nbd: to point to the source qemu-nbd >> 3) run qemu -incoming on the destination with the qed file >> 4) execute the migration >> 5) when migration completes, begin streaming on the destination to complete the copy >> 6) when the streaming is complete, shut down the qemu-nbd instance on the source >> >> This is a bit involved and we could potentially automate some of this in qemu by launching qemu-nbd and providing commands to do some of this. Again though, I think the question is what type of interfaces would libvirt prefer? Low level interfaces + recipes on how to do high level things or higher level interfaces? >> > Is there anything keeping us from making the QMP socket multiplexable? I was thinking of something like: > > { command = "nbd_server" ; block = "qemu_block_name" } > { result = "done" } > > > This way we don't require yet another port, don't have to care about conflicts and get internal qemu block names for free. > Possibly, but something that complicates life here is that an nbd session would be source -> destination but there's no QMP session between source -> destination. Instead, there's a session from source -> management node and destination -> management node so you'd have to proxy nbd traffic between the two. That gets ugly quick. Regards, Anthony Liguori > Alex > >