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@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list