From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=37101 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OOFqe-000261-Kp for qemu-devel@nongnu.org; Mon, 14 Jun 2010 16:01:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OOFqD-0007ep-Eo for qemu-devel@nongnu.org; Mon, 14 Jun 2010 16:01:06 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:55660) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OOFqD-0007ek-8x for qemu-devel@nongnu.org; Mon, 14 Jun 2010 16:01:05 -0400 Received: by iwn10 with SMTP id 10so4532019iwn.4 for ; Mon, 14 Jun 2010 13:01:04 -0700 (PDT) Message-ID: <4C168A81.8060302@codemonkey.ws> Date: Mon, 14 Jun 2010 15:01:05 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> <4C165482.6020601@linux.vnet.ibm.com> <4C167DE4.8080104@linux.vnet.ibm.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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 02:54 PM, Juan Quintela wrote: > Anthony Liguori wrote: > >> On 06/14/2010 01:35 PM, Juan Quintela wrote: >> > >>> 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. >> > In this case, I also want to know when migration ended. > > >>> 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? >> > That is the reason why I insist to have the events "both" in source and > destination. About how to integrate savevm on the whole picture .... > > VM_SAVE_START/VM_SAVE_END/VM_RESTORE_START/VM_RESTORE_END events? > If savevm is an asychronous command, then it's already there. You really want to support turning all command submissions/completions into events. You could do it with two events. The first would be COMMAND_REQUEST and would contain the request data and which monitor it occurred on. The second would be COMMAND_RESPONSE and would contain the response data and which monitor it occurred on. But honestly, I think it's a stretch to say this functionality is really needed. >> 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. >> > Agreed. That was also the reason why I told that the "write" commands > are "more interesting" in this regard. > > But now (at least in my point of view), we are moving in the right > direction. From "we can get this with polling + other workarounds" to > "this mechininsm could be useful for other things". > > Later, Juan. > >