From mboxrd@z Thu Jan 1 00:00:00 1970 From: Anthony Liguori Subject: Re: [RFC PATCH 00/20] Kemari for KVM v0.1 Date: Thu, 22 Apr 2010 14:42:29 -0500 Message-ID: <4BD0A6A5.7000106@linux.vnet.ibm.com> References: <1271829445-5328-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: kvm@vger.kernel.org, qemu-devel@nongnu.org, avi@redhat.com, Anthony Liguori , mtosatti@redhat.com, ohmura.kei@lab.ntt.co.jp, yoshikawa.takuya@oss.ntt.co.jp To: Yoshiaki Tamura Return-path: Received: from e37.co.us.ibm.com ([32.97.110.158]:57495 "EHLO e37.co.us.ibm.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1756761Ab0DVTmn (ORCPT ); Thu, 22 Apr 2010 15:42:43 -0400 Received: from d03relay02.boulder.ibm.com (d03relay02.boulder.ibm.com [9.17.195.227]) by e37.co.us.ibm.com (8.14.3/8.13.1) with ESMTP id o3MJf7lM018629 for ; Thu, 22 Apr 2010 13:41:07 -0600 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay02.boulder.ibm.com (8.13.8/8.13.8/NCO v9.1) with ESMTP id o3MJgf0m197078 for ; Thu, 22 Apr 2010 13:42:41 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.14.3/8.13.1/NCO v10.0 AVout) with ESMTP id o3MJgaiN020313 for ; Thu, 22 Apr 2010 13:42:38 -0600 In-Reply-To: <1271829445-5328-1-git-send-email-tamura.yoshiaki@lab.ntt.co.jp> Sender: kvm-owner@vger.kernel.org List-ID: On 04/21/2010 12:57 AM, Yoshiaki Tamura wrote: > Hi all, > > We have been implementing the prototype of Kemari for KVM, and we're sending > this message to share what we have now and TODO lists. Hopefully, we would like > to get early feedback to keep us in the right direction. Although advanced > approaches in the TODO lists are fascinating, we would like to run this project > step by step while absorbing comments from the community. The current code is > based on qemu-kvm.git 2b644fd0e737407133c88054ba498e772ce01f27. > > For those who are new to Kemari for KVM, please take a look at the > following RFC which we posted last year. > > http://www.mail-archive.com/kvm@vger.kernel.org/msg25022.html > > The transmission/transaction protocol, and most of the control logic is > implemented in QEMU. However, we needed a hack in KVM to prevent rip from > proceeding before synchronizing VMs. It may also need some plumbing in the > kernel side to guarantee replayability of certain events and instructions, > integrate the RAS capabilities of newer x86 hardware with the HA stack, as well > as for optimization purposes, for example. > > Before going into details, we would like to show how Kemari looks. We prepared > a demonstration video at the following location. For those who are not > interested in the code, please take a look. > The demonstration scenario is, > > 1. Play with a guest VM that has virtio-blk and virtio-net. > # The guest image should be a NFS/SAN. > 2. Start Kemari to synchronize the VM by running the following command in QEMU. > Just add "-k" option to usual migrate command. > migrate -d -k tcp:192.168.0.20:4444 > 3. Check the status by calling info migrate. > 4. Go back to the VM to play chess animation. > 5. Kill the the VM. (VNC client also disappears) > 6. Press "c" to continue the VM on the other host. > 7. Bring up the VNC client (Sorry, it pops outside of video capture.) > 8. Confirm that the chess animation ends, browser works fine, then shutdown. > > http://www.osrg.net/kemari/download/kemari-kvm-fc11.mov > > The repository contains all patches we're sending with this message. For those > who want to try, pull the following repository. At running configure, please > put --enable-ft-mode. Also you need to apply a patch attached at the end of > this message to your KVM. > > git://kemari.git.sourceforge.net/gitroot/kemari/kemari > > In addition to usual migrate environment and command, add "-k" to run. > > The patch set consists of following components. > > - bit-based dirty bitmap. (I have posted v4 for upstream QEMU on April 2o) > - writev() support to QEMUFile and FdMigrationState. > - FT transaction sender/receiver > - event tap that triggers FT transaction. > - virtio-blk, virtio-net support for event tap. > This series looks quite nice! I think it would make sense to separate out the things that are actually optimizations (like the dirty bitmap changes and the writev/readv changes) and to attempt to justify them with actual performance data. I'd prefer not to modify the live migration protocol ABI and it doesn't seem to be necessary if we're willing to add options to the -incoming flag. We also want to be a bit more generic with respect to IO. Otherwise, the series looks very close to being mergable. Regards, Anthony Liguori