From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=34796 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOC8j-0003wv-3F for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:03:59 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOC7o-0007CW-5Z for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:03:01 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45294) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOC7n-0007CR-VC for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:03:00 -0400 From: Juan Quintela In-Reply-To: <4C1636BC.704@linux.vnet.ibm.com> (Anthony Liguori's message of "Mon, 14 Jun 2010 09:03:40 -0500") References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> Date: Mon, 14 Jun 2010 18:02:20 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: qemu-devel@nongnu.org, Luiz Capitulino Anthony Liguori wrote: > On 06/12/2010 06:05 AM, Juan Quintela wrote: >> Luiz Capitulino 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.