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