Anthony Liguori <aligu...@linux.vnet.ibm.com> wrote: > On 06/12/2010 06:05 AM, Juan Quintela wrote: >> Luiz Capitulino<lcapitul...@redhat.com> 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.
