[libvirt] [Qemu-devel] Re: Libvirt debug API

Anthony Liguori anthony at codemonkey.ws
Thu Apr 22 18:45:27 UTC 2010

On 04/09/2010 09:27 AM, 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.
> So in both cases the API and XML format can be reasonably guarenteed
> between releases. What we can't guarentee is that usage  of these
> features will be reliable across releases of libvirt.
>> 2)  Again unlike other libvirt API's, access and configuration of
>> the debug section of a domain will be highly hypervisor dependent.
>> 3)  Application developers will be strongly discouraged from using
>> this API because of the above 2 issues.  To help in this, the
>> API's will be in a separate library that developers will explicitly
>> have to link to, and it will have a different (but largely compatible)
>> wire protocol.
> In terms of wire protocol, this would still have to run over the same
> existing data channel, because we don't want apps to have to open up
> multiple connections. Fortunately our protocol is designed to allow
> this kind of extension
>    struct remote_message_header {
>        unsigned prog;              /* REMOTE_PROGRAM */
>        unsigned vers;              /* REMOTE_PROTOCOL_VERSION */
>        remote_procedure proc;      /* REMOTE_PROC_x */
>        remote_message_type type;
>        unsigned serial;            /* Serial number of message. */
>        remote_message_status status;
>    };
> We currently have a single program 'REMOTE_PROGRAM' and its associated
> 'vers' and 'proc' numbers. What we would be doing is to define a new
> program, say QEMU_PROGRAM. The 'remote_procedure proc' numbers can thus
> start again from '1' without clashing with any of the existing APIs.
> All the RPC marshalling/demarshalling code should work more or less
> unchanged. We just hook in a different function dispatch table in the
> daemon for that program.
>> 4)  We don't expect this API to solve all of the issues brought up
>> during the qemud discussion.  Our initial goal is just to give
>> ready access of the qemu command-line and monitor to developers.
>> With that being said, our initial proposal follows.  We expect this
>> to evolve over time as we get more feedback, but we think this
>> proposal addresses at least 2 of the major pain points qemu developers
>> have while trying to use libvirt.
>> The initial debug XML for qemu would be:
> I wouldn't call them 'debug' options, since that's just one of possible
> use cases for this. What we're really doing there is exposing hypervisor
> specific features, so we should just be upfront about that in our
> description / naming.
>> <domain type='kvm'>
>>    <name>myguest</name>
>>    ...
>>    <debug>
>>      <monitorpassthrough/>
>>      <commandline>
>>        <extra>qemu arguments</extra>
>>        <alter option="optname">
>>          <rename>newname</rename>
>>          <match>REGEXP</match>
>>          <modify>foo=on</modify>
>>          <extra>-bar</extra>
>>        </alter>
>>      </commandline>
>>    </debug>
>> </domain>
> 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
>    <domain type='kvm' xmlns:qemu="http://libvirt.org/schemas/domain/qemu/1.0">
>      <name>myguest</name>
>      ...
>      <qemu:commandline>
>        <qemu:arg>-device</arg>
>        <qemu:arg>lsi</arg>
>      </qemu:commandline>
>    </domain>

I think it's problematic to focus too much on command line arguments.  
We are not introducing new command line arguments to qemu for the most 
part that aren't usable in the config file.

What I really think we would like, is a way to express the qemu 
configuration file in terms of XML and then to use snippets of that 
within an XML namespace.  For instance:

  name = "Opteron_G3"
  level = "5"
  vendor = "AuthenticAMD"

Could convert to:


Which in turn, could be embedded as:

<domain type='kvm' xmlns:qemu='http://qemu.org/schemas/qemu/1.0'>

With respect to injecting QMP commands directly, I think the proposed 
debug API is probably reasonable.  We could build a libqemu that used 
that API as a transport which means that one could use libqemu and 
libvirt simultaneously which is certainly a key requirement of mine.

I think it's important that it's a dedicated monitor session though.  It 
shouldn't just be injecting commands within an existing QMP session IMHO.


Anthony Liguori


Anthony Liguori

More information about the libvir-list mailing list