qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Jules
Subject: Re: [Qemu-devel] [PATCH v3 0/4] Curling: KVM Fault Tolerance
Date: Wed, 23 Oct 2013 13:23:11 +0800


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.
> 
> 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.

> - Michael
> 
> 
> 






reply via email to

[Prev in Thread] Current Thread [Next in Thread]