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

[Juan Quintela <quintela@redhat.com>]

Luiz Capitulino <lcapitulino@redhat.com> wrote:
> On Tue, 15 Jun 2010 12:30:57 +0200
> Juan Quintela <quintela@redhat.com> wrote:
>
>> Anthony Liguori <anthony@codemonkey.ws> wrote:
>> > On 06/14/2010 02:54 PM, Juan Quintela wrote:
>> >> Anthony Liguori<aliguori@linux.vnet.ibm.com>  wrote:
>> 
>> >>> What makes migration important and not savevm?
>> >>>      
>> >> That is the reason why I insist to have the events "both" in source and
>> >> destination.  About how to integrate savevm on the whole picture ....
>> >>
>> >> VM_SAVE_START/VM_SAVE_END/VM_RESTORE_START/VM_RESTORE_END events?
>> >>    
>> >
>> > If savevm is an asychronous command, then it's already there.
>> >
>> > You really want to support turning all command submissions/completions
>> > into events.   You could do it with two events.  The first would be
>> > COMMAND_REQUEST and would contain the request data and which monitor
>> > it occurred on.  The second would be COMMAND_RESPONSE and would
>> > contain the response data and which monitor it occurred on.
>> >
>> > But honestly, I think it's a stretch to say this functionality is
>> > really needed.
>> 
>> As already told, what I need is the migration ones.
>> 
>> The imporant case is MIGRATION_ENDED on target when migration were
>> sucessful.  This is the fast path, and it makes a difference here.
>
>  I think we could avoid this one too, but as it has a clear feature for
> 0.13, I'm not too opposed either.
>
>> MIGRATION_STARTED on target is also quite "nice" to have.  At this point
>> libvirt has an
>> 
>> sleep(250ms): echo "cont"
>> 
>> Due to a race here in incoming migration.
>
>  Hm. Did you investigate that race in detail? I hope we're not using events
> to hide bugs.

Yes.  we can call "cont" while staying in "waiting for incomming
migration" because we dont' have "waiting incoming migraiton" than
vm_start/stop understand.

Reviewing all callers to see that I can add a new state.

>> As we only wanted one ending event, can agree on:
>> 
>> MIGRATION_STARTED(both source and target)
>> MIGRATION_DONE(result) (both source and target)
>> 
>> where result can be ok or -1 (at this point we don't have anything else
>> to put there).
>> 
>> That moves us from 4 events to 2?
>
>  I still don't see the need for MIGRATION_STARTED, it could be useful in
> the target but I'd like to understand the use case in more detail.

At this point, if you are doing migration with tcp, and you are putting
the wrong port on source (no path or any other error), you get no info
at all of what is happening.

It is important to be sure than migration has started, i.e. something
happenend.  It happens to me all the time, and users with more complex
setup will like it to know what is happening.

As a workaround, we can try something like "info status" or ony read
only version to know that migration is not happening (because) monitor
is working (as I tell an workaround).

Later, Juan.