qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Juan Quintela
Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events
Date: Mon, 14 Jun 2010 21:54:43 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux)

Anthony Liguori <address@hidden> 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?

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]