text: On 04/09/2010 09:27 AM, Daniel P. Berrange. 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..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: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:
  [cpudef] name = "Opteron_G3" level = "5" vendor = "AuthenticAMD" ... Could convert to: <cpudef> <name>Operon_G3</name> <level>5</level> <vendor>AuthenticAMD</vendor> ... </cpudef> Which in turn, could be embedded as: <domain type='kvm' xmlns: <name>myguest</name> ... <qemu:cpudef> <name>Operon_G3</name> <level>5</level> <vendor>AuthenticAMD</vendor> </qemu:cpudef> </domain it's important that it's a dedicated monitor session though. It shouldn't just be injecting commands within an existing QMP session IMHO.
  Regards, Anthony Liguori Regards, Anthony Liguori