From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=43935 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Pu32w-0005na-Mh for qemu-devel@nongnu.org; Mon, 28 Feb 2011 08:21:55 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Pu32v-00021L-4q for qemu-devel@nongnu.org; Mon, 28 Feb 2011 08:21:54 -0500 Received: from mx1.redhat.com ([209.132.183.28]:41526) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Pu32u-00020t-Mk for qemu-devel@nongnu.org; Mon, 28 Feb 2011 08:21:53 -0500 Message-ID: <4D6BA16A.2020204@redhat.com> Date: Mon, 28 Feb 2011 15:21:46 +0200 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [patch 2/3] Add support for live block copy References: <20110222170004.808373778@redhat.com> <20110222170115.710717278@redhat.com> <4D642181.4080509@codemonkey.ws> <20110222210735.GA9372@amt.cnet> <4D64266A.3060106@codemonkey.ws> <20110222230935.GA11082@amt.cnet> <4D644343.4050800@codemonkey.ws> <4D65051A.6070707@redhat.com> <4D651B20.70405@codemonkey.ws> <4D652852.60505@redhat.com> <4D652F73.3000305@codemonkey.ws> <4D65324A.5080408@redhat.com> <4D65359E.3040008@codemonkey.ws> <4D65416D.8040803@redhat.com> <4D656B97.5030301@codemonkey.ws> <4D661CB8.6010305@redhat.com> <4D667287.9010005@codemonkey.ws> <4D6677BE.2030009@redhat.com> <4D669C46.40909@codemonkey.ws> <4D6A150B.8030205@redhat.com> <4D6A58E0.9020607@codemonkey.ws> <4D6A6E38.4030700@redhat.com> <4D6A8CC9.4090304@codemonkey.ws> <4D6B5EFA.8060106@redhat.com> <4D6B98FD.7020103@codemonkey.ws> In-Reply-To: <4D6B98FD.7020103@codemonkey.ws> 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: Anthony Liguori Cc: Jes.Sorensen@redhat.com, Marcelo Tosatti , qemu-devel@nongnu.org On 02/28/2011 02:45 PM, Anthony Liguori wrote: > On 02/28/2011 02:38 AM, Avi Kivity wrote: >>> >>> We don't separate configuration from guest state today. Instead of >>> setting ourselves up for failure by setting an unrealistic standard >>> that we try to achieve and never do, let's embrace the system that >>> is working for us today. We are authoritative for everything and >>> guest state is intimately tied to the virtual machine configuration. >> >> "we are authoritative for everything" is a clean break from >> everything that's being done today. It's also a clean break from the >> model of central management plus database. We can't force it on people. > > No, it isn't. This has been the way QEMU has always been. > > QEMU has always and will always continue to be useful in the absence > of a management layer. That means that it will mix modifications to > configuration with guest actions. > > To avoid races, a management tool needs to either poll QEMU or listen > for events to know when QEMU initiates a configuration change. This > is how tools are written today. > > The only thing being discussed is how to handle a very small and rare > race condition whereas QEMU may send an notification to a crashed > management tool *and* QEMU crashes before the management tool restarts. > > The only two options to solve this problem are synchronous > notifications or a QEMU global state file. Since the former is a > radical change to our existing API, the later is a much more > reasonable option. > > If a management tool doesn't care about this race, it can simply not > use the global state file. You're just ignoring what I've written. -- error compiling committee.c: too many arguments to function