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

[Juan Quintela <quintela@redhat.com>]

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

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.

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

I haven't looked at the trace commands that you pointed (so no comment
there), but I see it "interesting" to be able to know what commands have
been issued from other monitor.

In my ideal world, I would get a monitor from libvirt, where I could
play.  And libvirt will look at the commands that I issue and decided if
he can continue or just leave the guest for me.

Notice the "ideal world" part O:-)

Adiso, Juan.