[Xen-devel] [PATCH 0/5] Testing libvirt XML -> libxl_domain_config conversion

["Daniel P. Berrange" <berrange@xxxxxxxxxx>]

At the Xen Hackathon I learnt that libxl provides an API which
can serialize a libxl_domain_config instance to a JSON document.
This is exactly what we need for testing the XML -> libxl_domain_config
conversion process, so I spent the afternoon trying to get such a test
working. The result is that we can now just add pairs of XML, JSON
files to libvirt to test handling of new config features.

I hit a couple of small issues with libxl, which I worked around, when
writing this test which I why I'm copying xen-devel

 - libxl_ctx_alloc() will call xs_daemon_open and xc_interface_open,
   and stat /var/run/xenstored.pid to see if Xen is actually running.
   This fails when run on non-Xen hosts (and also possibly if run
   unprivileged).

   I used an evil LD_PRELOAD hack to stub out xs_daemon_open and
   xc_interface_open to return (void*)0x1, and also turn
   xc_interface_close and xs_daemon_close to no-ops, and make
   stat() always return success for xenstored.pid.

   This works (evidenced by the fact that if something was needing
   these xs/xc handles they would have crashed referencing 0x1), 
   but at the same time it might be an idea to have an officially
   supported  "non live" mode for libxl_ctx_alloc() turned on by a
   flag of some sort.


 - The libxl_json.h header file is relying on conditionals that
   are only set by Xen's build process

    eg HAVE_YAJL_YAJL_VERSION_H

   I hacked around this, but it is a little dirty too. libvirt
   already links to libyajl for the QEMU driver, but we  don't
   really need the raw YAJL objects. It'd be nice to have a

      char * libxl_domain_config_as_json(libxl_domain_config *p)

   as a higher level wrapper around libxl_domain_config_gen_json
   avoiding the pain of dealing with YAJL's different APIs.

   Ian J mentioned to me that he thought there was already such a
   method, but AFAICT, the only such code is in the 'xl' command
   line tool itself (xl_cmdimpl.c - printf_info_one_json)


A few further ideas that could be done as a followup

 - Make virConnectDomainXMLToNative accept 'xl-json" as a
   data format, so you can feed in a libvirt XML and get back
   out a JSON document. This could be a useful debugging tool
   for Xen developers trying to identify bugs in libvirt.

 - Write out the JSON document to /var/log/libvirt/libxl/$GUEST.log
   whenever starting a guest. Again this would be a useful debugging
   aid to Xen developers / support people trying to identify why a
   guest might be mis-behaving


Regards,
Daniel

Daniel P. Berrange (5):
  Don't pass virDomainObjPtr to libxlBuildDomainConfig
  Don't pass libxlDriverPrivatePtr into libxlBuildDomainConfig
  libxl: Move virDomainXMLOptionNew into libxlCreateXMLConf
  Add more test suite mock helpers
  Add a test suite for libxl option generator

 src/libxl/libxl_conf.c               |  38 +++---
 src/libxl/libxl_conf.h               |  10 +-
 src/libxl/libxl_domain.c             |   7 +-
 src/libxl/libxl_driver.c             |   4 +-
 tests/Makefile.am                    |  25 +++-
 tests/libxlxml2jsondata/minimal.json | 172 +++++++++++++++++++++++++++
 tests/libxlxml2jsondata/minimal.xml  |  36 ++++++
 tests/libxlxml2jsontest.c            | 219 +++++++++++++++++++++++++++++++++++
 tests/virfirewalltest.c              |   4 +-
 tests/virmock.h                      |  54 ++++++---
 tests/virmocklibxl.c                 |  87 ++++++++++++++
 tests/virsystemdtest.c               |   4 +-
 12 files changed, 617 insertions(+), 43 deletions(-)
 create mode 100644 tests/libxlxml2jsondata/minimal.json
 create mode 100644 tests/libxlxml2jsondata/minimal.xml
 create mode 100644 tests/libxlxml2jsontest.c
 create mode 100644 tests/virmocklibxl.c

-- 
1.9.3


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel