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