From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O1Ly3-0005wZ-BQ for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:54:31 -0400 Received: from [140.186.70.92] (port=36775 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O1Ly1-0005uA-56 for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:54:30 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O1Lxy-0004Fp-Vm for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:54:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:17076) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O1Lxy-0004FM-No for qemu-devel@nongnu.org; Mon, 12 Apr 2010 11:54:26 -0400 Received: from int-mx03.intmail.prod.int.phx2.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.16]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o3CFsMrV021502 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 12 Apr 2010 11:54:23 -0400 Date: Mon, 12 Apr 2010 12:20:13 -0300 From: Luiz Capitulino Subject: Re: [Qemu-devel] Re: [libvirt] Libvirt debug API Message-ID: <20100412122013.58894a64@redhat.com> In-Reply-To: <20100409142717.GA11875@redhat.com> References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Libvirt , Jiri Denemark , Chris Lalancette , qemu-devel@nongnu.org On Fri, 9 Apr 2010 15:27:17 +0100 "Daniel P. Berrange" wrote: > On Fri, Apr 09, 2010 at 09:41:39AM -0400, Chris Lalancette wrote: > > Hello, > > In response to a lot of the talk of qemud lately on qemu-devel, the > > libvirt community would like to put forward a proposal to help enable > > debug/advanced options when using various hypervisors. The goals of > > this API are: > > > > 1) To enable more rapid access to hypervisor features before proper > > libvirt API's are designed around them. > > 2) To facilitate debugging and access to advanced features that may > > not fit into the normal libvirt world-view. > > > > Caveats: > > 1) Unlike other libvirt API's, this one will explicitly *not* be > > guaranteed ABI/API compatible between libvirt updates. > > I think we'd still aim to keep the public API stable. The bit that we > can't guarentee is the interactions with QEMU & the libvirt driver. > eg, if someone was using the API to send text monitor commands to > QEMU, and the next libvirt release switched to JSON mode, that use > would break. The API would still be valid, but the way they use it > might not be. Similarly if they add some custom extra command line > argument, this could potentially conflict with an extra command line > arg a subsquent libvirt release used. eg, they used -device to add > a PCI card with a specific PCI address. Then next libvirt release > specifies this same PCI address and then you get a clash. Another problem is issuing Monitor commands that could confuse libvirt's real API. Say, adding a device libvirt doesn't know about or stopping the VM while libvirt thinks it's still running or anything like that. When I suggested the monitor passthrough idea, I thought it could be a workaround for the feature time lag problem, but as stated by Avi, I'm afraid that this can potentially cause more problems than it solves. It's very desirable for debugging (item 2 above) and maybe to try new things, but people couldn't use it for anything serious, which is the major issue in this subject (item 1 above). Now, Anthony's idea of having libqemu has the same issues, which seems to mean that the only way to really fix the time lag is to fix the time lag :) > > Raw access to the qemu monitor will be disabled by default; the > > tag enables the ability to send QMP (or > > text, if you are using older qemu) messages straight through to the > > monitor. To do this there will be an additional API entry point > > named virDomainDebugCommand() which takes an arbitrary string > > and passes it to the monitor, and returns an arbitrary string as > > a result. Thus you could pass in either "info cpus" if using the > > text monitor or '{ "execute": "query-cpus" }' if using QMP. > > Again the idea of a 'virDomainDebugCommand' API is QEMU specific, with > other hypervisors have different approaches for low level extension/ > debug. For example, Xen would involve XenStore access, or XenD XMLRPC, > etc. So this should really live in a separate API namespace which is > specific to a hypervisor. For example, as a header file > > #include > > Containing APIs like > > int virDomainQEMUInvokeMonitor(virDomainPtr dom, > const char *command, > char **reply); > > typedef virConnectQEMUDomainEventCallback(virConnectPtr conn, > virDomainPtr dom, > const char *eventname, > const char *data, > void *opaque) > int virConnectQEMUDomainEventRegister(virConnectPtr conn, > virDomainPtr dom, > const char *eventname, > virDomainQEMUMonitorCallback cb, > void *opaque); What about all the wonders of json? This will force clients to have their own json <-> text converter, maybe we could provide two APIs, just like qemu driver works internally?