From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1MJ4UW-0003rz-2w for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:48:44 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1MJ4UQ-0003o8-U3 for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:48:43 -0400 Received: from [199.232.76.173] (port=34289 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1MJ4UQ-0003ns-OQ for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:48:38 -0400 Received: from mx1.redhat.com ([66.187.233.31]:51963) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1MJ4UQ-0000cc-AU for qemu-devel@nongnu.org; Tue, 23 Jun 2009 07:48:38 -0400 Date: Tue, 23 Jun 2009 12:48:33 +0100 From: "Daniel P. Berrange" Message-ID: <20090623114833.GJ6881@redhat.com> 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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4A40BC66.8040206@redhat.com> Subject: [Qemu-devel] Re: [PATCH 11/11] QMP: Command-line flag to enable control mode Reply-To: "Daniel P. Berrange" List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: aliguori@us.ibm.com, ehabkost@redhat.com, Jan Kiszka , dlaor@redhat.com, qemu-devel@nongnu.org, Luiz Capitulino On Tue, Jun 23, 2009 at 02:28:38PM +0300, Avi Kivity wrote: > On 06/23/2009 01:54 PM, Jan Kiszka wrote: > >>It would be a nightmare, consider both libvirt and a user hotplugging > >>something into the same pci slot, or a user starting migration, or > >>quitting, or ... > >> > > > >Migration, yes, but hot-plugging is resolvable - given config update > >events. > > > > I'm not saying it's impossible, just that we don't want to do it. > > >>Having -monitor readonly makes sense. > >> > > > >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. Regards, Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|