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