Anthony Liguori<address@hidden> wrote:
On 06/14/2010 11:02 AM, Juan Quintela wrote:
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.
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.