From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=47183 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OMSG6-0005iT-NW for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OMSG5-0001C4-KU for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:22 -0400 Received: from mx1.redhat.com ([209.132.183.28]:14324) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OMSG5-0001Bv-9j for qemu-devel@nongnu.org; Wed, 09 Jun 2010 16:52:21 -0400 Date: Wed, 9 Jun 2010 17:52:15 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] [PATCH v3 0/5] Add QMP migration events Message-ID: <20100609175215.2e2071a0@redhat.com> In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Juan Quintela Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org On Wed, 9 Jun 2010 14:10:53 +0200 Juan Quintela wrote: > 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. Something which is not clear to me is the set of events we'd have if migrate was an async command. Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get this information from the async response? > > 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(-) > >