[libvirt] RFC: Import / export of Domain XML from/to native "formats"
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.
> - 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 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