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

[Anthony Liguori <aliguori@linux.vnet.ibm.com>]

On 06/14/2010 01:35 PM, Juan Quintela wrote:
> Anthony Liguori<aliguori@linux.vnet.ibm.com>  wrote:
>    
>> On 06/14/2010 11:02 AM, Juan Quintela wrote:
>>      
>>> Anthony Liguori<aliguori@linux.vnet.ibm.com>   wrote:
>>>
>>>        
>>>> On 06/12/2010 06:05 AM, Juan Quintela wrote:
>>>>
>>>>          
>>>>> Luiz Capitulino<lcapitulino@redhat.com>    wrote:
>>>>>
>>>>>            
>>>
>>>        
>>>>> 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.
>>>>>
>>>>>
>>>>>            
>>>> Dual monitors is a slippery slope argument because even if you had
>>>> these events, it doesn't give you nearly enough information to
>>>> implement anything safely.
>>>>
>>>>          
>>> Security folks here needed to do logging of qemu events, here.  Guest
>>> what ones: vm_start, vm_stop, vm_continue, and vm_migrate.
>>>
>>>        
>> Why do security folks need this?  Why are they not interested in other
>> things like savevm?  Why are they talkign to qemu and not libvirt
>> (they shouldn't trust qemu).
>>      
> No clue about last one.  I just was asked to provide that list of
> events.  will ask back.
>
>    
>>> Insteod of a nice: write this "small qmp client, and listen for this
>>> four events, I just had to point them where to hack their logging.
>>>
>>> About libvirt, I would rreally, really like to be able to use libvirt to
>>> launch a guest, and then let im me launch another monitor and stoup
>>> libvirt for continuing with it.  There is no way for a monitor that
>>> there has been doing "write" operations in other monitors.  I see this
>>> as a useful feature for all "write" (i.e. not query) commands.
>>>
>>>        
>> Yeah, but if we want to do this, then we need to discuss this with the
>> libvirt folks and come up with a proposal that works for all commands.
>> Sneaking in a few migration events is not going to help.
>>      
> Fully agree.
>
>    
>>> Migration commands have a "feature" that dont' have other commands: they
>>> invosve two machines.
>>>
>>> And I would also liked to have that events for all the "write" commands.
>>> Migration is more "interesting" becaues it needs synchronization.
>>>
>>>        
>> I'm still fundamentally confused about what you think you can do with
>> these events.  But do you really intend on introducing events for
>> every non-query QMP command?  Does that seem a bit unrealistic?
>>      
> 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.

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

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.

Regards,

Anthony Liguori