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

[Anthony Liguori <anthony@codemonkey.ws>]

On 06/14/2010 02:54 PM, Juan Quintela wrote:
> Anthony Liguori<aliguori@linux.vnet.ibm.com>  wrote:
>    
>> On 06/14/2010 01:35 PM, Juan Quintela wrote:
>>      
>    
>>> Ok. lets stop here.  My definitions:
>>>
>>> Event: this important thing happened (important has several meanings).
>>>
>>> Migration events fully enter in this definition.  Furthermore, migration
>>> events happens from actions that are issued in machine A and event
>>> happens in machine A and machine B. (I.e. they are so special as they
>>> can get).
>>>
>>>        
>> I think you've got too narrow a view.  Migration doesn't always
>> involve two machines.  Migration can involve just the source writing
>> via "exec:dd of=foo.img" and this is in fact an important use case for
>> libvirt.
>>      
> In this case, I also want to know when migration ended.
>
>    
>>> Now convenience.  I "think" it would be convenient to also know in the
>>> other monitors when any "write" command happens.  About how to implement
>>> this, if there are more uses or no, .... that is clearly open to
>>> discussion.  I think that this enter fully in the politics vs mechanism
>>> discussions, events allow you to notify when things happen, and
>>> management app can do anything that it sees fit.
>>>
>>> As principle, I think that "important happenings" (to not repeat the
>>> "event" word) should be published in a very clear way.  Migration
>>> start/end are a basic example of that.  It is not as if Migration is
>>> going to stop having a "start" or an "end" any time soon.  Making the
>>> app polling to know that is too cumbersome for the "normal" good case.
>>> This kind of things should be plublished "somehow".  The same that
>>> happens when a machine start/stops.  That are improntant events.
>>>
>>>        
>> 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.

>> It's not that I don't agree that migration is important and that it's
>> important for tools to be able to know about it.  I disagree that
>> migration is *more* important than most of the other things that
>> happen in the monitor and I want to make sure that we come up with a
>> solution that solves the broader problem.
>>      
> Agreed.  That was also the reason why I told that the "write" commands
> are "more interesting" in this regard.
>
> But now (at least in my point of view), we are moving in the right
> direction.  From "we can get this with polling + other workarounds" to
> "this mechininsm could be useful for other things".
>
> Later, Juan.
>
>