From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=48690 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMK7f-0006An-CU for qemu-devel@nongnu.org; Wed, 09 Jun 2010 08:11:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMK7a-0000nH-EJ for qemu-devel@nongnu.org; Wed, 09 Jun 2010 08:11:07 -0400 Received: from mx1.redhat.com ([209.132.183.28]:4059) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMK7a-0000n3-75 for qemu-devel@nongnu.org; Wed, 09 Jun 2010 08:11:02 -0400 Received: from int-mx08.intmail.prod.int.phx2.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.21]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o59CB149009681 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 9 Jun 2010 08:11:01 -0400 From: Juan Quintela Date: Wed, 9 Jun 2010 14:10:53 +0200 Message-Id: Subject: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org This is a resent with what we agreed on yesterday call. Migration events would be there for 0.13 until we get proper async command support. Later, Juan. v3: - Add comment that MIGRATION_FAILURE will add a QError for 0.14 (when we get internal support for that) rebase against today tree v2: - Address pbonzini and mst changes (error messages and doc fixes) v1: This series does: - exit incoming migration on failure. For exec/fd migrations, once there was a failure, there was nothing useful to do. And for tcp migration, not exiting created interesting bugs when trying to migrate again to a process with a faild migration. - Factorize common migration code, no more duplication, makes easier to do "global" migration things, like QMP events. - Introduce QMP events, both for incoming and outgoing migration. Now, the million dollar question: Why I didn't refactorize outgoing migration? I tried, and have it partially done on my local tree. But it depends (too much) of current_migration global variable -> Libvirt folks will also want "info migrate" to work on the incoming side, i.e. current_migraition has to also be updated on incoming side. Done until here, but then I hit the wall "incoming migration is synchronous". To make the monitor work on incoming migration, we need to change buffered_file.c abstraction to also work for incoming fd's, or another similar solution. I am open to suggestions about what to do here. This series are quite simple (the unfinished part is more complex), will send the other part as an RFC later. Please review and consider to apply it. Later, Juan. Juan Quintela (5): Exit if incoming migration fails Factorize common migration incoming code QMP: Introduce MIGRATION events QMP: Emit migration events on incoming migration QMP: Emit migration events on outgoing migration QMP/qmp-events.txt | 52 ++++++++++++++++++++++++++++++++++++++++++++++++++++ migration-exec.c | 17 +++-------------- migration-fd.c | 15 ++------------- migration-tcp.c | 17 ++++------------- migration-unix.c | 17 ++++------------- migration.c | 37 +++++++++++++++++++++++++++++++------ migration.h | 4 +++- monitor.c | 12 ++++++++++++ monitor.h | 4 ++++ vl.c | 7 ++++++- 10 files changed, 121 insertions(+), 61 deletions(-)