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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list