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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Fri, 2014-05-30 at 18:24 +0100, Daniel P. Berrange wrote:
> 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.

Yes, we absolutely should have this.

>  - 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
> 

It looks like this header has ended up with a mixture of library
internal and user facing stuff, which is wrong. I think splitting the
internal stuff into libxl_json_internal.h or similar would solve this.
I'll take a look.

>    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)

That was me not Ian J I think.

The function you need is libxl_domain_config_to_json (which is
autogenerated, so in _libxl_types.[hc]). I think the general
libxl_*_to_json support has been there since Xen 4.2, but IIRC
libxl_domain_config only got moved into the autogenerated/IDL layer in
4.3.

For compatibility with 4.2 you could probably use libxl_*_to_json on the
various members of libxl_domain_config individually, or just punt on the
unit tests in that case of course...

Ian.


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