2010/6/10 Luiz Capitulino <lcapitul...@redhat.com>: > On Wed, 9 Jun 2010 14:10:53 +0200 > Juan Quintela <quint...@redhat.com> 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?
There would be two types of MIGRATION_FAILED. One for errors happen during setup of live migration, and one for during the process of live migration. The former is a synchronous event, and later would be an asynchronous event (if you didn't use -d option, this should also be a synchronous event). I'm not sure whether we should distinguish these failures or not. Yoshi > >> >> 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(-) >> >> > > >