From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ53K-0004Ot-Ol for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:24:43 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ53F-0004FA-GC for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:24:41 -0400 Received: from [199.232.76.173] (port=56733 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ53E-0004ES-Gr for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:24:36 -0400 Received: from mx2.redhat.com ([66.187.237.31]:46014) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ53C-0001JL-C0 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 08:24:35 -0400 Message-ID: <4A40C9B7.7040005@redhat.com> Date: Tue, 23 Jun 2009 15:25:27 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode References: <20090623013005.39e27923@doriath> <4A409A4D.8030605@siemens.com> <20090623100428.GD6881@redhat.com> <4A40AA3D.2050807@siemens.com> <4A40AB9D.6040204@redhat.com> <4A40B467.7000604@siemens.com> <4A40BC66.8040206@redhat.com> <20090623114833.GJ6881@redhat.com> In-Reply-To: <20090623114833.GJ6881@redhat.com> 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: "Daniel P. Berrange" Cc: aliguori@us.ibm.com, ehabkost@redhat.com, Jan Kiszka , dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On 06/23/2009 02:48 PM, Daniel P. Berrange wrote: >>> But not for all features, only those libvirt is capable to handle (I >>> think there are quite a few qemu specifics libvirt does not bother >>> about) and only as long as there is no proper synchronization. Again, >>> migration and save/restore will continue to require exclusive access, >>> but the rest is just a question of proper synchronization IMHO. >>> >>> >> If libvirt "doesn't bother" about something useful, that's a libvirt >> bug. It's wierd to have something controlled by two parallel management >> channels. >> > > It is not neccessaryily a 'bug'. The issue is that there is always a > potential time lag between a feature appearing in QEMU, and it being > fully supported in libvirt. So it is not a case of "doesnt' bother", > but rather 'not yet known about'. I think we should make it possible > for apps to be robust in this scenario, by allowing them to lockdown > 2ndary monitor channels readonly. > In this case I don't see much of an issue, since the time to implement a feature in libvirt is probably much shorter than the time needed to implement a proper GUI, database support, etc. that's needed for most features. Short cutting through another interface is likely to cost more time than it saves. -- error compiling committee.c: too many arguments to function