From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O5Jxe-0001XJ-Dp for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:34:30 -0400 Received: from [140.186.70.92] (port=48184 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O5Jxd-0001WJ-12 for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:34:29 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O5Jxa-0002lP-Ss for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:34:28 -0400 Received: from mx1.redhat.com ([209.132.183.28]:48228) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O5Jxa-0002lA-Ld for qemu-devel@nongnu.org; Fri, 23 Apr 2010 10:34:26 -0400 Date: Fri, 23 Apr 2010 15:34:15 +0100 From: "Daniel P. Berrange" Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API Message-ID: <20100423143415.GF17700@redhat.com> References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> <20100412122013.58894a64@redhat.com> <4BD09A3B.3090001@codemonkey.ws> <4BD1971B.7060907@redhat.com> <4BD1A543.1050004@codemonkey.ws> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4BD1A543.1050004@codemonkey.ws> Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Libvirt , qemu-devel@nongnu.org, Luiz Capitulino , Chris Lalancette , Avi Kivity , Jiri Denemark On Fri, Apr 23, 2010 at 08:48:51AM -0500, Anthony Liguori wrote: > On 04/23/2010 07:48 AM, Avi Kivity wrote: > >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. > > Let's consider some concrete examples. I'm using libvirt and QMP and in > QMP, I want to hot unplug a device. > > Today, I do this by listing the pci devices, and issuing a pci_del that > takes a PCI address. This is intrinsically racy though because in the > worst case scenario, in between when I enumerate pci devices and do the > pci_del in QMP, in libvirt, I've done a pci_del and then a pci_add > within libvirt of a completely different device. This is what already happens with any QEMU >= 0.12, where libvirt uses the new -device syntax with its 'id' parameter for all devices, and then uses 'device_id $ID' for unplug. The app still has to be careful it doesn't try to add a device using the same naming scheme as a device libvirt uses. This is easy enough though if they prepend some random string to all device IDs thy use, that won't clash with libvirt device ID names. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://deltacloud.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|