From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5IJG-0006JR-Oc for qemu-devel@nongnu.org; Fri, 23 Apr 2010 08:48:42 -0400 Received: from [140.186.70.92] (port=48387 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5IJE-0006J9-3y for qemu-devel@nongnu.org; Fri, 23 Apr 2010 08:48:42 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5IJC-0002z1-95 for qemu-devel@nongnu.org; Fri, 23 Apr 2010 08:48:39 -0400 Received: from mx1.redhat.com ([209.132.183.28]:6113) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5IJC-0002yr-1i for qemu-devel@nongnu.org; Fri, 23 Apr 2010 08:48:38 -0400 Message-ID: <4BD1971B.7060907@redhat.com> Date: Fri, 23 Apr 2010 15:48:27 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> In-Reply-To: <4BD09A3B.3090001@codemonkey.ws> Content-Type: text/plain; charset=UTF-8; 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: Libvirt , Jiri Denemark , Chris Lalancette , qemu-devel@nongnu.org, Luiz Capitulino On 04/22/2010 09:49 PM, Anthony Liguori wrote: >> real API. Say, adding a device libvirt doesn't know about or stopping >> the VM >> while libvirt thinks it's still running or anything like that. > Another problem is issuing Monitor commands that could confuse > libvirt's > > We need to make libvirt and qemu smarter. > > We already face this problem today with multiple libvirt users. This > is why sophisticated management mechanisms (like LDAP) have mechanisms > to do transactions or at least a series of atomic operations. And people said qmp/json was overengineered... But seriously, transactions won't help anything. qemu maintains state, and when you have two updaters touching a shared variable not excepting each other to, things break, no matter how much locking there is. The only way that separate monitors could work is if they touch completely separate state, which is difficult to ensure if you upgrade your libvirt. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic.