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

[Michael R. Hines]

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.

Would you be interested in "joining forces"? You even picked
a cool name (I didn't even choose a name)..... =)

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)?

- Michael