From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=40311 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOCFj-0000cg-0b for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:11:12 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOCFh-0000Bh-KD for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:11:10 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:55898) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOCFh-0000BO-HK for qemu-devel@nongnu.org; Mon, 14 Jun 2010 12:11:09 -0400 Received: from d01relay05.pok.ibm.com (d01relay05.pok.ibm.com [9.56.227.237]) by e6.ny.us.ibm.com (8.14.4/8.13.1) with ESMTP id o5EG9c7w022694 for ; Mon, 14 Jun 2010 12:09:38 -0400 Received: from d03av03.boulder.ibm.com (d03av03.boulder.ibm.com [9.17.195.169]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5EGB7Y7097738 for ; Mon, 14 Jun 2010 12:11:07 -0400 Received: from d03av03.boulder.ibm.com (loopback [127.0.0.1]) by d03av03.boulder.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5EGAh6F007606 for ; Mon, 14 Jun 2010 10:10:43 -0600 Message-ID: <4C165482.6020601@linux.vnet.ibm.com> Date: Mon, 14 Jun 2010 11:10:42 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: Juan Quintela Cc: qemu-devel@nongnu.org, Luiz Capitulino On 06/14/2010 11:02 AM, Juan Quintela wrote: > 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. > 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). > 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. >> 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. > 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? Wouldn't it be better to have a mechanism to snoop on monitor traffic in a more proper way? Regards, Anthony Liguori > Later, Juan. >