Anthony Liguori<address@hidden> 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.
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.