Anthony Liguori <anth...@codemonkey.ws> wrote: > On 05/25/2010 09:21 AM, Juan Quintela wrote:
>> +MIGRATION_CANCELED >> +------------------ >> + >> +Emitted when migration is canceled. This is emitted in the source. >> +Target will emit MIGRATION_FAILED (no way to differentiate a FAILED >> +and CANCELED migration for target). >> > > But the management tool is the one that cancels so surely, it knows > why already. ok, then that one is ok. > >> +Data: None >> + >> +Example: >> + >> +{ "event": "MIGRATION_CANCELED", >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } >> + >> +MIGRATION_ENDED >> +--------------- >> + >> +Emitted when migration ends (both in source and target) >> > > A start event is going to be generated already, no? problem here is that libvirt start target with -S, and waits to do the "cont" as soon as possible. As of know, only way to do it is to poll info migrate on source faster. >> +Data: None >> + >> +Example: >> + >> +{ "event": "MIGRATION_ENDED", >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } >> + >> +MIGRATION_FAILED >> +---------------- >> + >> +Emitted when migration fails (both is source and target). >> + >> +Data: None >> > > There should be some information about why it failed, no? Preferrably > in a QError format. At this point, we have basically -1 :( I can add a field with an error number, but we are very bad at the moment about moving errno's upstack. >> +Example: >> + >> +{ "event": "MIGRATION_FAILED", >> + "timestamp": {"seconds": 1274687575, "microseconds": 592483} } >> + >> +MIGRATION_STARTED >> +----------------- >> + >> +Emitted when migration starts (both in source and target). >> > > I think this makes more sense as a MIGRATION_CONNECTED event. It > probably should carry peer information too. What kind of peer information? We have tcp/fd/exec/unix migrations. calling it CONNECTED vs STARTED, I don't care. But adding information? Notice that the management application knows what it did, I can put the: "exec: gzip -d < /tmp/foo" string, but not much more that I can put here. Later, Juan.