[libvirt] RFC: Import / export of Domain XML from/to native "formats"

Daniel Veillard veillard at redhat.com
Tue Apr 14 13:54:22 UTC 2009


On Tue, Apr 14, 2009 at 01:20:00PM +0100, Daniel P. Berrange wrote:
> Some of the frequently asked questions I see floating around various
> user forums / mailing lists wrt libvirt XML, relate the import or export
> of existing configurations from/to libvirt.
> 
> eg
> 
>  - What is the libvirt XML matching the QEMU args 'qemu -foo -bar -wiz'
> 
>  - What are the QEMU arguments used by libvirt for XML config XYZ
> 
>  - What is the libvirt XML matching the Xen file XYZ in /etc/xen
> 
>  - What is the Xen config file corresponding to the libvirt XML XYZ
> 
> 
> When those questions arise, the best we do is point the user at wiki page
> or XML format docs, sometimes give them some examples, etc

  Agreed, people get confused.

> It occurred to me that we could do much better than this. We already have
> code in libvirt that knows how todo
> 
>  - libvirt XML -> QEMU args
>  - libvirt XML -> Xen config file
>  - Xen config file -> libvirt XML
>  - Xen SEXPR -> libvirt XML
>  - libvirt XML -> Xen SEXPR
> 
> it is not possible to access this functionality directly though - it is used
> internally via things like the DumpXML / DefineXML commands. It would be
> helpful to be able to use these conversion functions directly in many cases,
> to be able to do conversions, without having to actually define a new VM.
> 
> I did a proof of concept creating some tools
> 
>  - virt-xml-from-qemu-args
>  - virt-xml-to-qemu-args
>  - virt-xml-from-xen-config
>  - virt-xml-to-xen-config
>  - virt-xml-from-xen-sxpr
>  - virt-xml-to-xen-sxpr

  Yes I think that would be useful in a less crude form, for example
someone wanting to know if KVM "-vga std" is supported could just pass
this to the tool and get tha assciated construct or an error indicating
the given args are not suported in that form

> that just linked directly to the internal conversion APIs. This is a bit of
> a hack though, and I think it might be preferable to have a formal public
> API for invoking the conversions, instead of restricting them to a set of
> command line tools.

  yes. That could be useful to cleanup some of the regression testing
tools linking too.

> What I think we could do is:
> 
>  -  char *virConnectDomainXMLExport(const char *nativeFormat, const char *xml)
> 
>      Export 'xml' doc from libvirt XML to a config in 'nativeFormat', 
>      returning the native config data
> 
>  -  char *virConnectDomainXMLImport(const char *nativeFormat, const char *config)
> 
>      Import 'config' data in 'nativeFormat', to libvirt XML,
>      returning the libvirt XML doc
> 

  Looks fine, I would still use an extra flags argument for future
  expansion, it ended up being useful even for virDomainDumpXML so I
  guess there too.

> The 'nativeFormat' would be a hypervisor specific format. The QEMU driver
> would initially provide a format called 'qemu-argv'. The Xen driver would
> provide 2 formats 'xen-xm' and 'xen-sxpr'. Later the QEMU driver might
> also provide 'qemu-conf' as & when QEMU gets  native config file format.

  I guess an extra function which would list the supported formats for
a given hypervisor would allow to make closure here.

    char ***virConnectDomainListFormats(const char *hypervisor);

or added to the capabilities XML output.

> Most of the hard code for these functions already exists. The only one
> missing is the QEMU ARGV -> libvirt XML conversion, but its not too hard
> to get a basic impl up & running.
> 
> In virsh, we might expose
> 
>     virsh domxml-export  [XMLFILE  [CONFIGFILE]]
>     virsh domxml-import  [CONFIGFILE [XMLFILE]]
> 
> Both these would read/write from/to  STDIN/STDOUT, if their optional filename
> args were ommitted.

  yup that sounds fine.

Daniel

-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/




More information about the libvir-list mailing list