Re: [libvirt] RFC: Import / export of Domain XML from/to native "formats"
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(a)veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/