Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance

["Michael R. Hines" <mrhines@linux.vnet.ibm.com>]

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:<address>:<port>
>>>          ->  migrate -f tcp:<address>:<port>
>>>
>>> * 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