From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtexZ-0007jt-E0 for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:29:41 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtexU-0007h8-Hz for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:29:40 -0400 Received: from [199.232.76.173] (port=48597 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtexU-0007h5-CS for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:29:36 -0400 Received: from lizzard.sbs.de ([194.138.37.39]:23927) by monty-python.gnu.org with esmtps (TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1LtexT-0003fT-Su for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:29:36 -0400 Message-ID: <49E4577A.70602@siemens.com> Date: Tue, 14 Apr 2009 11:29:30 +0200 From: Jan Kiszka 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=ISO-8859-1 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: Hollis Blanchard , libvir-list@redhat.com, qemu-devel@nongnu.org, Jan Kiszka , Avi Kivity 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. ...while there is also nothing that speaks against blocking any device hot-plugging while migration is ongoing. Independent of if there is some management app involved or the user himself plays with multiple monitors. Jan -- Siemens AG, Corporate Technology, CT SE 2 Corporate Competence Center Embedded Linux