[Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events

[Juan Quintela]

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.

I have been needinng this for audit, knowing when guest
start/stop/migrates.  And just now the only way to get that information
is to "hack" qemu source code.  With migration_events it will be
"trivial" to know when that happens.

In libvirt case.  First thing that I would do if I receive a
MIGRATION_START command that I didn't started: I release control of that
VM, something fishy happened.  At this point, it is imposible to know
what happens.

>> - 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.

>>   This event is emmited on all source and target monitors.
>>   - For 0.13: Event don't have a QError.
>>   - For 0.14: It will gain a QError.
>> 
>>   About migration becoming an async command.  Really it is independent
>>   of what events we emit.  If migration becomes async command, only
>>   difference is for the monitor that emitted the command, rest of
>>   monitors see nothing.  If we want to be able to see that informantion
>>   in the other monitors, we need the events anyways.
>
>  Somewhere else in this discussion someone has said that we should assume
> that the client talking to the source is the same one which is going to
> talk to the target, in this case all the communication is done through
> the source qemu instance.

That is another problem, that we don't have a monitor in the destination
target during migration.

Later, Juan.