From: Lei Li <lilei@linux.vnet.ibm.com>
To: qemu-devel@nongnu.org
Cc: aarcange@redhat.com, aliguori@us.ibm.com,
Lei Li <lilei@linux.vnet.ibm.com>,
quintela@redhat.com, lagarcia@br.ibm.com, pbonzini@redhat.com,
rcj@linux.vnet.ibm.com
Subject: [Qemu-devel] [PATCH 0/12 RFC v2] Localhost migration
Date: Fri, 26 Jul 2013 04:18:07 +0800 [thread overview]
Message-ID: <1374783499-2550-1-git-send-email-lilei@linux.vnet.ibm.com> (raw)
Hi,
This patch series tries to add localhost migration support to
Qemu.
When doing localhost migration, the host memory will balloon
up during the period, might consume double memories for some time.
So we want to add a new live migration mechanism localhost
migration.
Following I copied from last version that Anthony added for the
benefit of the other reviewers:
The goal here is to allow "live upgrade" of a running QEMU instance.
The work flow would look like this:
1) Guests are running QEMU release 1.6.1
2) Admin installs QEMU release 1.6.2 via RPM or deb
3) Admin does localhost migration with page flipping to use new version
of QEMU.
Page flipping is used in order to avoid requiring that there is enough
free memory to fit an additional copy of the largest guest which is the
requirement today with localhost migration.
You can also read from the link below:
http://lists.gnu.org/archive/html/qemu-devel/2013-06/msg02577.html
The plan is:
1) Add new command to do localhost migration.
The qmp interface introduced like:
{ 'command': 'localhost-migrate', 'data': {'uri': 'str'} }
2) Use different mechanism than current live migration.
The very basic work flow like:
qemu on the source (the source and destination are both on localhost)
|
V
Stop VM
|
V
Create threads
|
V
Page flipping through vmspice
|
V
MADV_DONTNEED the ram pages which are already flipped
|
V
Migration completes
As stopping VM first, we expect/resume the page flipping through vmspice
is fast enough to meet *live migration (low downtime).
Notes:
Currently the work flow is not exactly the same as description
above. For the first step, the work flow we implemented is:
stop VM and copy ram pages via unix domain socket, MADV_DONTNEED
ram pages that already copied. After that, will replace to vmsplice
mechanism instead of copying pages.
Now it's still a draft version, and as it is implemented separately
to the current migration code for a easy start, the next step will
be trying to integrate it into the current migration implementation
closely. To make sure we are on the right direction that should be
headed, please let me know your suggestions on this.
For the interface, as Anthony has suggested using a flag or a
capability, which one would you prefer or any ideas?
Your comments are very welcome!
TODO:
- Integrate to the current implement of migration closely?
- Introduce a mechanism to exchange a PIPE via SCM_RIGHTS.
- benchmark/evaluation.
Lei Li (12):
migration: export MIG_STATE_xxx flags
savevm: export qemu_save_device_state()
rename is_active to is_block_active
arch_init: introduce ram_page_save()
arch_init: introduce ram_save_local()
arch_init: add save_local_setup to savevm_ram_handlers
savevm: introduce qemu_savevm_local()
savevm: adjust is_ram check in register_savevm_live()
migration-local: implementation of outgoing part
migration-local: implementation of incoming part
migration-local: add option to command line for local incoming
hmp:add hmp_localhost_migration interface
Makefile.objs | 1 +
arch_init.c | 110 +++++++++++++++++++
block-migration.c | 2 +-
hmp-commands.hx | 17 ++++
hmp.c | 13 +++
hmp.h | 1 +
include/migration/migration.h | 32 +++++++
include/sysemu/sysemu.h | 1 +
migration-local.c | 228 +++++++++++++++++++++++++++++++++++++++++
migration-unix.c | 60 ++++++++++++
migration.c | 8 --
qapi-schema.json | 14 +++
qemu-options.hx | 9 ++
qmp-commands.hx | 22 +++++
savevm.c | 100 +++++++++++++++--
vl.c | 14 +++
16 files changed, 613 insertions(+), 19 deletions(-)
create mode 100644 migration-local.c
next reply other threads:[~2013-07-25 20:19 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-07-25 20:18 Lei Li [this message]
2013-07-25 20:18 ` [Qemu-devel] [PATCH 01/12] migration: export MIG_STATE_xxx flags Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 02/12] savevm: export qemu_save_device_state() Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 03/12] rename is_active to is_block_active Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 04/12] arch_init: introduce ram_page_save() Lei Li
2013-08-02 19:40 ` Michael R. Hines
2013-08-05 2:49 ` Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 05/12] arch_init: introduce ram_save_local() Lei Li
2013-08-02 19:42 ` Michael R. Hines
2013-08-05 3:27 ` Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 06/12] arch_init: add save_local_setup to savevm_ram_handlers Lei Li
2013-08-02 19:43 ` Michael R. Hines
2013-07-25 20:18 ` [Qemu-devel] [PATCH 07/12] savevm: introduce qemu_savevm_local() Lei Li
2013-08-02 19:48 ` Michael R. Hines
2013-08-05 3:02 ` Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 08/12] savevm: adjust is_ram check in register_savevm_live() Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 09/12] migration-local: implementation of outgoing part Lei Li
2013-08-02 19:45 ` Michael R. Hines
2013-08-05 3:18 ` Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 10/12] migration-local: implementation of incoming part Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 11/12] migration-local: add option to commandline for incoming-local Lei Li
2013-08-02 19:46 ` Michael R. Hines
2013-08-05 3:21 ` Lei Li
2013-07-25 20:18 ` [Qemu-devel] [PATCH 12/12] hmp: add hmp_localhost_migration interface Lei Li
2013-08-02 19:47 ` Michael R. Hines
2013-08-05 3:22 ` Lei Li
2013-07-26 9:41 ` [Qemu-devel] [PATCH 0/12 RFC v2] Localhost migration Paolo Bonzini
2013-08-05 8:56 ` Lei Li
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1374783499-2550-1-git-send-email-lilei@linux.vnet.ibm.com \
--to=lilei@linux.vnet.ibm.com \
--cc=aarcange@redhat.com \
--cc=aliguori@us.ibm.com \
--cc=lagarcia@br.ibm.com \
--cc=pbonzini@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=quintela@redhat.com \
--cc=rcj@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).