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

[Juan Quintela]

Anthony Liguori <address@hidden> wrote:
> On 06/12/2010 06:05 AM, Juan Quintela wrote:
>> Luiz Capitulino<address@hidden>  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.

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.

> If you truly want to support dual uncooperative monitors, you
> basically need to mirror every monitor session so that each monitor
> can see what the other monitors are doing.  You also need a
> transaction mechanism to allow a client to do operations in a non-racy
> way.

For now, I will set with just knowing that other "write" operations has 
happened.

> Since we're not likely to ever implement these things, dual monitor
> support is really not a viable argument for such a change.

As showed before for the audit logging, A "read only" monitor would have
been useful for me "now", i.e. not I wish, whatever.

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


Later, Juan.