From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38198) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2S0W-0008RX-FD for qemu-devel@nongnu.org; Thu, 25 Jul 2013 16:19:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1V2S0V-0005Ou-Do for qemu-devel@nongnu.org; Thu, 25 Jul 2013 16:19:28 -0400 Received: from e28smtp08.in.ibm.com ([122.248.162.8]:53559) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1V2S0U-0005Nl-UG for qemu-devel@nongnu.org; Thu, 25 Jul 2013 16:19:27 -0400 Received: from /spool/local by e28smtp08.in.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Fri, 26 Jul 2013 01:39:18 +0530 Received: from d28relay02.in.ibm.com (d28relay02.in.ibm.com [9.184.220.59]) by d28dlp02.in.ibm.com (Postfix) with ESMTP id C1A82394002D for ; Fri, 26 Jul 2013 01:49:05 +0530 (IST) Received: from d28av03.in.ibm.com (d28av03.in.ibm.com [9.184.220.65]) by d28relay02.in.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id r6PKK8wk41287916 for ; Fri, 26 Jul 2013 01:50:08 +0530 Received: from d28av03.in.ibm.com (loopback [127.0.0.1]) by d28av03.in.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id r6PKJ9nK016988 for ; Fri, 26 Jul 2013 06:19:10 +1000 From: Lei Li Date: Fri, 26 Jul 2013 04:18:07 +0800 Message-Id: <1374783499-2550-1-git-send-email-lilei@linux.vnet.ibm.com> Subject: [Qemu-devel] [PATCH 0/12 RFC v2] Localhost migration List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: aarcange@redhat.com, aliguori@us.ibm.com, Lei Li , quintela@redhat.com, lagarcia@br.ibm.com, pbonzini@redhat.com, rcj@linux.vnet.ibm.com 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