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.