From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Ltf65-000785-KH for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:38:29 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Ltf60-000770-QB for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:38:28 -0400 Received: from [199.232.76.173] (port=37714 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Ltf60-00076s-5I for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:38:24 -0400 Received: from mx2.redhat.com ([66.187.237.31]:44756) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Ltf5x-0004ju-IA for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:38:23 -0400 Message-ID: <49E459AE.2080201@redhat.com> Date: Tue, 14 Apr 2009 12:38:54 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) 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> <20090414091726.GL14297@redhat.com> In-Reply-To: <20090414091726.GL14297@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: libvir-list@redhat.com, Jan Kiszka , qemu-devel@nongnu.org, Hollis Blanchard Daniel P. Berrange wrote: > 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. > What if the system triggers migration automatically (as you'd expect). And that's just one example. I'm sure there are more. libvirt issues commands expecting some state in qemu. It can't learn of that state from listening on another monitor, because there are delays between the state changing and the notification. If you want things to work reliably, you have to follow the chain of command. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.