From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1O0ImO-0005PV-On for qemu-devel@nongnu.org; Fri, 09 Apr 2010 14:18:08 -0400 Received: from [140.186.70.92] (port=43252 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1O0ImM-0005NH-Jc for qemu-devel@nongnu.org; Fri, 09 Apr 2010 14:18:08 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1O0ImJ-0000Vv-Cd for qemu-devel@nongnu.org; Fri, 09 Apr 2010 14:18:06 -0400 Received: from mx1.redhat.com ([209.132.183.28]:23464) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1O0ImJ-0000Vo-1s for qemu-devel@nongnu.org; Fri, 09 Apr 2010 14:18:03 -0400 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o39II2IC018081 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Fri, 9 Apr 2010 14:18:02 -0400 Message-ID: <4BBF6EE6.5080803@redhat.com> Date: Fri, 09 Apr 2010 14:16:06 -0400 From: Chris Lalancette MIME-Version: 1.0 References: <4BBF2E93.3020508@redhat.com> <20100409142717.GA11875@redhat.com> In-Reply-To: <20100409142717.GA11875@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [libvirt] Libvirt debug API List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: "Daniel P. Berrange" Cc: Libvirt , Jiri Denemark , qemu-devel@nongnu.org On 04/09/2010 10:27 AM, Daniel P. Berrange wrote: > The concept of command line & monitor is something that is QEMU specific > and thus is not suitable for the primary XML schema. IMHO, this needs to be > done as a separate schema, linked in via an XML namespace. For example > > > myguest > ... > > -device > lsi > > This is a very good idea. I didn't really know about namespaces, but now that you've pointed them out I think this is a great way to partition it up. I'll start looking at this. > > >> >> 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); > > > For an add-on library > > libvirt-qemu.so > > I don't think there's much to be gained from having an XML element to > turn on/off use of these APIs. If an app doesn't want to use them, it > can simply not link to libvirt-qemu.so The reason I wanted to do this was mostly for debug/support reasons. That is, with this element in place we can easily tell from the dumpxml output whether a person was using the "unreliable" API's, and thus we can tell them to try and reproduce without that in place. > >> The tag does exactly what you might expect; appends >> the exact string to the qemu command-line. > > Allowing many args at once in the blob means that libvirt will > need to parse & split this up into individual args which than then be > safely passed to 'exec'. It is better to specify one arg per element > to avoid this fragile parsing problem. That is true. However, it's nicer to the user (and more like the qemu command-line) to specify the options as one big string. In any case we already have the code for parsing a qemu command-line (for the native-to-xml API), so we can just adapt that. > >> The tag gets more interesting. The idea is that would >> allow you to modify the libvirt-generated qemu command-line in arbitrary >> ways. How this would work is probably best explained with some examples: >> >> >> >> -netdev >> >> >> >> In this example, all options named -net on the qemu command-line are >> renamed to -netdev. >> >> In this example, if (and only if) a -net option is seen, then -usbtablet is >> appended to the qemu command-line. >> >> >> >> \(.*name=hostnet0.*\) >> \1,tap >> >> >> >> This gets more complicated (but also more powerful). In this case, any -net > > I think this alteration of existing args is faaaar too complex & fragile, > and way overkill. If the arg that libvirt generates isn't what someone > needs, then remove the bit of the guest config responsible for that and > add a complete extra arg, rather than munging the existing one. It is complex, I agree. I also think it is pretty powerful. But if the need arises, we can always add it later. For now we'll go with just the monitor passthrough and simple command-line addition, and we can evolve from there. -- Chris Lalancette