On Tue, Jan 11, 2011 at 05:19:08PM -0700, Eric Blake wrote:
Right now, the daemon-conf test fires up an instance of libvirtd,
but
that instance tries to probe the installed location of cpu_map.xml
rather than an in-tree location, which means the test is liable to fail
if run on a just built but uninstalled binary:
I/O warning : failed to load external entity
"/usr/local/share/libvirt/cpu_map.xml"
17:10:50.357: 14549: warning : qemuCapsInit:774 : Failed to get host CPU
I'm not sure how to go about isolating the test from the installation
directory, since libvirtd currently doesn't have any way (either via
command line argument or via the temp.conf file) to override the
preferred location of other files such as cpu_map.xml. Maybe a new
libvirtd.conf entry is called for, which defaults to the installation
location, but which daemon-conf munges to the in-tree location before
passing --conf-file to the libvirtd instance.
This problem is just yet another example of why the daemon-conf
test suite is flawed. We shouldn't be running the libvirtd daemon
as part of the unit tests. This test is design to verify the
configuration file loading abilities....we should change the
code so that we can directly unit test those capabilities, instead
of indirectly testing.
With my RPC patches, the configuration file code has been isolated
into a separate unit that can be tested by unit tests. Likewise the
overall daemon, RPC server & RPC client code, can all now be unit
tested.
For the short term until I replace this test case, I'd just add a
gross hack to 'detect' if we're run from source tree, in libvirtd
startup code eg
if (getenv("abs_srcdir"))
virAsprintf(&dir, "%s/%s", getenv("abs_srcdir"),
"src/cpu/cpu_map.xml");
cpuMapOverride(dir);
VIR_FREE(dir);
Daniel