From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve80y-0003Rj-44 for qemu-devel@nongnu.org; Wed, 06 Nov 2013 13:39:49 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Ve80p-0001Uq-6D for qemu-devel@nongnu.org; Wed, 06 Nov 2013 13:39:40 -0500 Received: from e39.co.us.ibm.com ([32.97.110.160]:49646) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Ve80o-0001UY-Ve for qemu-devel@nongnu.org; Wed, 06 Nov 2013 13:39:31 -0500 Received: from /spool/local by e39.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 6 Nov 2013 11:39:30 -0700 Received: from b01cxnp23034.gho.pok.ibm.com (b01cxnp23034.gho.pok.ibm.com [9.57.198.29]) by d01dlp01.pok.ibm.com (Postfix) with ESMTP id 0303A38C8042 for ; Wed, 6 Nov 2013 13:39:27 -0500 (EST) Received: from d01av05.pok.ibm.com (d01av05.pok.ibm.com [9.56.224.195]) by b01cxnp23034.gho.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id rA6IdKW5000466 for ; Wed, 6 Nov 2013 18:39:28 GMT Received: from d01av05.pok.ibm.com (localhost [127.0.0.1]) by d01av05.pok.ibm.com (8.14.4/8.14.4/NCO v10.0 AVout) with ESMTP id rA6IctUh020391 for ; Wed, 6 Nov 2013 13:38:55 -0500 Message-ID: <527A8CA7.1060808@linux.vnet.ibm.com> Date: Wed, 06 Nov 2013 13:38:31 -0500 From: "Michael R. Hines" MIME-Version: 1.0 References: <1381821983-13932-1-git-send-email-junqing.wang@cs2c.com.cn> <5266E75F.9060300@linux.vnet.ibm.com> <1382505791.1720.30.camel@localhost> In-Reply-To: <1382505791.1720.30.camel@localhost> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Jules Cc: qemu-devel@nongnu.org, pbonzini@redhat.com, owasserm@redhat.com, "Michael R. Hines" , Juan Jose Quintela Carreira On 10/23/2013 01:23 AM, Jules wrote: > > On 2013-10-22 17:00 -0400，Michael R. Hines wrote： >> On 10/15/2013 03:26 AM, Jules Wang wrote: >>> v2 -> v3: >>> * add documentation of new option in qapi-schema. >>> >>> * long option name: ft -> fault-tolerant >>> >>> v1 -> v2: >>> * cmdline: migrate curling:tcp:
: >>> -> migrate -f tcp:
: >>> >>> * sender: use QEMU_VM_FILE_MAGIC_FT as the header of the migration >>> to indicate this is a ft migration. >>> >>> * receiver: look for the signature: >>> QEMU_VM_EOF_MAGIC + QEMU_VM_FILE_MAGIC_FT(64bit total) >>> which indicates the end of one migration. >>> -- >>> Jules Wang (4): >>> Curling: add doc >>> Curling: cmdline interface. >>> Curling: the sender >>> Curling: the receiver >>> >>> arch_init.c | 25 ++++-- >>> docs/curling.txt | 51 ++++++++++++ >>> hmp-commands.hx | 10 ++- >>> hmp.c | 3 +- >>> include/migration/migration.h | 1 + >>> include/migration/qemu-file.h | 1 + >>> include/sysemu/sysemu.h | 5 +- >>> migration.c | 50 ++++++++++-- >>> qapi-schema.json | 6 +- >>> qmp-commands.hx | 3 +- >>> savevm.c | 178 +++++++++++++++++++++++++++++++++++++++--- >>> 11 files changed, 303 insertions(+), 30 deletions(-) >>> create mode 100644 docs/curling.txt >>> >> Jules, I think we should work together. The patches I sent this week >> solve all of the problems (and more) of Kemari and have been in >> testing for over 1 year. >> >> 1. I/O buffering is already working >> 2. Checkpoint parallelism is already working >> 3. Staging of the checkpoint memory is already working >> on both the sender side and receiver side. >> 3. Checkpoint chunking is already working (this means that checkpoints >> can be very large and must be split up like slab caches, >> which can dynamically grow and shrink as the amount of >> diryt memory in the virtual machine fluctuates. >> 4. RDMA checkpointing is already working >> 5. TCP checkpointing is already working >> 6. There does not need to be a custom migration URI >> - this is easily implemented through a capability. >> 7. Libvirt support is already available on github. >> 8 There is no need to modify the QEMU migration metadata state information. >> >> All of these features take advantage of the recent advances >> in QEMU in migration performance improvements over the last >> few years. > I will read your patches carefully as a good learning material. Cool - I'm back from travelling. Sorry for the delayed response. I look forward to a review from you of the code - I'm excited to get some kind review going. >> Would you be interested in "joining forces"? You even picked >> a cool name (I didn't even choose a name)..... =) > Yes, your solution is better than mine obviously, and we could work > together to improve your patches. >> Also: I will soon be working in IBM China Beijing, for 3 years - starting >> next month - perhaps we could talk on the phone (or meet in person)? > Welcome to Beijing and take some dust masks with you, you will need > them. :) > I prefer email or meet in person if necessary. I will read and try your > patches first. Thank you - I will reach out to you once I've arrived. - Michael