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

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

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

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

>> QMP is the wrong mechanism for this.  Merging the tracing code and
>> then adding trace points to migration is the right solution for this
>> problem.
>>      
>    
>> The problem is, all of the arguments you're using to justify this for
>> the migrate command is applicable for every other command we have.
>> Why do this for migrate and not for commit or savevm?
>>
>> Do we really want to introduce 4 events for every command that we support?
>>      
> 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?

Wouldn't it be better to have a mechanism to snoop on monitor traffic in 
a more proper way?

Regards,

Anthony Liguori

> Later, Juan.
>