Luiz Capitulino<address@hidden> wrote:
On Thu, 10 Jun 2010 12:44:55 +0200
Juan Quintela<address@hidden> wrote:
Luiz Capitulino<address@hidden> wrote:
On Wed, 9 Jun 2010 14:10:53 +0200
Juan Quintela<address@hidden> 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?
I am not able to define simpler semantics for this events:
Ok, I must be missing something here.
First, let's talk about how async commands work today, better yet, how they
should work in 0.14.
I see two possible interfaces (off the top of my head):
1. QMP only returns the response when the command is finished, eg:
C: { "execute": "migrate", "id": "foo" ... }
/* nothing is returned, other commands are issued, after several hours...
*/
S: { "return": ... "id": "foo" }
2. QMP returns a response right away just to signal that the command
has been accepted:
C: { "execute": "migrate", "id": "foo" ... }
S: { "return": {}, "id": "foo" ... }
However, the actual response is emitted as an event:
S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" }
That's what I have in mind, that's why I'm confused about what we're
trying to accomplish here.
You continue forgeting the case that you have more than one monitor
conected. The other monitor will not receive _ethire_ of that
responses. Will not know what is happening.
- MIGRATION_STARTED: somebody started a migration, it is emited on
source and target, all monitors receive this event.
The client has started the migration, it knows it. Why is the event needed?
The monitor that did it knows it, nobody else knows it. At destination
time, I guess you agree this is important, i.e. the management app knows
that migration has started.
- MIGRATION_ENDED: migration ended with sucess, all needed data is in
target machine. Also emitted in all monitors on source and target.
- MIGRATION_CANCELED: in one of the source monitors somebody typed:
migrate_cancel. It is only emmited on the source monitors, target
monitors will receive a MIGRATION_FAILED event.
- MIGRATION_FAILED (with this error). At this point we don't have
neither the QMP infraestructure for sending (with this error) nor
migration infrastructure to put there anything different than -1.
Aren't all the three events above duplicating the async response?
Again, no. Think that you have more than one monitor.
And indeed in the case of a single monitor. We are delaying the
information to the target management app.
MIGRATION_ENDED on target machine: We can do whatever is needed when
migration has ended. Async (or sync) answer to the source management
app, it needs to receive that information + send that information to
destination machine + receive information in destination machine + do
whatever is needed on destination vm.
Just because we refuse to give Information that we have, ready.
I am not asking for something that is difficult to do in qemu, it is
information that qemu knows (when migration has started/ended). And we
are telling management apps that they need to guess when things happens
and use polling to know it.