From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37464 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOF0C-0002DA-SV for qemu-devel@nongnu.org; Mon, 14 Jun 2010 15:07:22 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOF0B-0007Ya-Fm for qemu-devel@nongnu.org; Mon, 14 Jun 2010 15:07:20 -0400 Received: from e6.ny.us.ibm.com ([32.97.182.146]:35831) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOF0B-0007Y3-BW for qemu-devel@nongnu.org; Mon, 14 Jun 2010 15:07:19 -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 o5EJ5j3u014142 for ; Mon, 14 Jun 2010 15:05:45 -0400 Received: from d01av02.pok.ibm.com (d01av02.pok.ibm.com [9.56.224.216]) by d01relay05.pok.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id o5EJ7E49126848 for ; Mon, 14 Jun 2010 15:07:14 -0400 Received: from d01av02.pok.ibm.com (loopback [127.0.0.1]) by d01av02.pok.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id o5EJ7ElN013110 for ; Mon, 14 Jun 2010 16:07:14 -0300 Message-ID: <4C167DE4.8080104@linux.vnet.ibm.com> Date: Mon, 14 Jun 2010 14:07:16 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> <4C165482.6020601@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 01:35 PM, Juan Quintela wrote: > Anthony Liguori wrote: > >> 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). >> > 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). > I think you've got too narrow a view. Migration doesn't always involve two machines. Migration can involve just the source writing via "exec:dd of=foo.img" and this is in fact an important use case for libvirt. > 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. > What makes migration important and not savevm? It's not that I don't agree that migration is important and that it's important for tools to be able to know about it. I disagree that migration is *more* important than most of the other things that happen in the monitor and I want to make sure that we come up with a solution that solves the broader problem. Regards, Anthony Liguori