From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KWc2q-00025n-8Q for qemu-devel@nongnu.org; Fri, 22 Aug 2008 15:11:36 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KWc2n-00023x-JW for qemu-devel@nongnu.org; Fri, 22 Aug 2008 15:11:33 -0400 Received: from [199.232.76.173] (port=43926 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KWc2n-00023W-61 for qemu-devel@nongnu.org; Fri, 22 Aug 2008 15:11:33 -0400 Received: from mail2.shareable.org ([80.68.89.115]:39949) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1KWc2m-0005ud-RR for qemu-devel@nongnu.org; Fri, 22 Aug 2008 15:11:33 -0400 Date: Fri, 22 Aug 2008 20:11:28 +0100 From: Jamie Lokier Subject: Re: [Xen-devel] Re: [Qemu-devel] [PATCH 12/13] set vnc password from xenstore. Message-ID: <20080822191128.GG24179@shareable.org> References: <1219336054-15919-1-git-send-email-kraxel@redhat.com> <1219336054-15919-13-git-send-email-kraxel@redhat.com> <48ADCCA2.8050201@codemonkey.ws> <20080821201955.GG1531@redhat.com> <48ADCE91.2070602@codemonkey.ws> <48ADDF71.5040209@redhat.com> <20080821214806.GJ1531@redhat.com> <48AE64F5.3090303@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <48AE64F5.3090303@redhat.com> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: xen-devel@lists.xensource.com Gerd Hoffmann wrote: > Daniel P. Berrange wrote: > >> Multiple monitor instances would be very useful anyway. > >> > >> Right now there is no way to use the monitor for libvirt-managed qemu > >> instances because libvirt uses the monitor. Being able to both use > >> libvirt *and* have a monitor prompt to type commands would be great. > > > > I disagree - that means you'll no longer be able to trust what libvirt > > tells you about the VM, and libvirt won't have a guarenteed consistent > > view of the VM's state because things will be changed behind its back. > > It is *not* the only purpose of the monitor to confuse libvirt. The > whole 'info ' command family is very useful for development and > debugging purposes and it will not interfere at all with libvirt. > > I can't stand your attitude to refuse any feature just because you fear > users might abuse it. That applies to almost any feature which makes > life easier for developers. Which in turn means using libvirt for > development is either a bit complicated or impossible. I think it's good for libvirt to constrain and protect users, if it's targetting regular VM users. There are too many ways to accidentally break what can be valuable VMs. But if that's mandatory (can't bypass it when wanted), it should acknowledge that libvirt is _not_ suitable for people wanting to use advanced QEMU functionality - and QEMU features must not be designed to assume libvirt. It would be nice to manage VMs with a tool like libvirt _and_ still have access to the low-level stuff like the QEMU monitor, and the command line that libvirt generates. Maybe that's asking too much and we have to choose one or the other. -- Jamie