From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ltelq-00048F-MB for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:17:34 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ltelm-000472-W7 for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:17:34 -0400 Received: from [199.232.76.173] (port=48788 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltell-00046y-UP for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:17:30 -0400 Received: from mx1.redhat.com ([66.187.233.31]:39235) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ltell-00023T-KE for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:17:29 -0400 Date: Tue, 14 Apr 2009 10:17:26 +0100 From: "Daniel P. Berrange" Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) Message-ID: <20090414091726.GL14297@redhat.com> References: <49DE229B.7050408@redhat.com> <49DE2580.2030507@us.ibm.com> <49DE29C5.6010601@redhat.com> <49DE3321.4090900@us.ibm.com> <49E0C47F.9070501@redhat.com> <49E0FB00.8080500@codemonkey.ws> <49E10823.8060200@redhat.com> <20090412184217.GB4394@shareable.org> <20090414083016.GF14297@redhat.com> <49E4542B.8020808@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <49E4542B.8020808@redhat.com> Reply-To: "Daniel P. Berrange" , qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Avi Kivity Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard On Tue, Apr 14, 2009 at 12:15:23PM +0300, Avi Kivity wrote: > Daniel P. Berrange wrote: > >Yes indeed its a little crazy :-) As anthony mentioned if libvirt were > >able to be notified of changes a user makes in the monitor, there's no > >reason we could not allow end users to access the monitor of a VM > >libvirt is managing. We just need to make sure libvirt doesn't miss > >changes like attaching or detaching block devices, etc, because that'll > >cause crash/data loss later when libvirt migrates or does save/restore, > >etc because it'll launch QEMU with wrong args > > > > You still have an inherent race here. > > user: plug in disk > libvirt: start migration, still without disk > qemu: libvirt, a disk has been plugged in. That is true, but we'd still be considering direct monitor access to be a 'expert' user mode of use. If they wish to shoot themselves in the foot by triggering a migration at same time they are hotplugging I'm fine if their whole leg gets blown away. 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 :|