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@veillard.com | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/