From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LtejT-0003cC-4n for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:15:07 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LtejN-0003Zn-Oc for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:15:06 -0400 Received: from [199.232.76.173] (port=56165 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LtejN-0003Ze-8l for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:15:01 -0400 Received: from mx2.redhat.com ([66.187.237.31]:38069) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LtejL-00011y-2f for qemu-devel@nongnu.org; Tue, 14 Apr 2009 05:15:01 -0400 Message-ID: <49E4542B.8020808@redhat.com> Date: Tue, 14 Apr 2009 12:15:23 +0300 From: Avi Kivity MIME-Version: 1.0 Subject: Re: [libvirt] Re: [Qemu-devel] [PATCH 1/6] Allow multiple monitor devices (v2) References: <49DE1AD2.2060600@redhat.com> <49DE1DB3.30402@us.ibm.com> <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> In-Reply-To: <20090414083016.GF14297@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; 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" , qemu-devel@nongnu.org Cc: libvir-list@redhat.com, Jan Kiszka , Hollis Blanchard 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. >> I don't see how adding those low-level monitory things to libvirt is >> an improvement - debugging and scripted keystrokes are not the sort of >> functionality libvirt is for - or is it? >> > > I think it could probably be argued that sending fake keystrokes could > be within scope. Random ad-hoc debugging probably out of scope. > That means that to debug a problem in the field you have to locate a guest's host, and follow it around as it migrates (or disable migration). -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain.