The attached patch adds a new driver which provides a 'mock' hypervisor connection. The idea behind this is to provide a completely predictable and isolated hypervisor implementation, which will facilitate creation of unit tests in applications using libvirt. The code attached is not a complete implementation, providing support only for connecting, listing domains, getting a domain by id/uuid/name, getting domain info, getting node info. Further work will hook up methods for creating domains, exporting XML & the other various libvirt APIs. The driver is intended to operate as a black box, closed system - the only interaction an application will have is via the libVirt entry points. It starts off with a single domain present, and fixed node info, and updates domain CPU time based on elapsed wall clock time. When the domain create API is hooked up this will let apps create new dummy domains within the context of the process. As I said, I delibrately implemented this driver to only have process local state. When the process shuts down all state is discarded. This keeps application usage very simple. Longer term I think it would be useful to have a 2nd, dynamic, which would allow fault injection, cross-process interaction & more to allow advanced scripting of a test scenario. I don't have time to create such a driver myself though, so I stuck with the simplest possible impl which will allow 95% of application unit testing needs to be satisfied. To use this driver, simply pass 'TestSimple' as the name parameter to virConnectOpen / virConnectOpenReadonly instead of NULL. If you are using 'virsh' then my previous patch will let you call 'virsh --connect TestSimple' I've also tested this with the 'gnome-vm-applet' panel applet. The only problem I have found is that the 'xend_internal.c' driver will always return success from its 'xenDaemonOpen' method, regardless of whether there is actually a Xen Daemon present. So when using the test driver, every method will first try to ue the XenD driver impl, fail (printing an error message) and then go onto use the test driver. The xenDaemonOpen method really needs to be fixed to only succeed when Xen is actually present. Or perhaps it should only try to run when the 'name' passed to virConnectOpen is NULL or 'Xen' - ie be a no op if the name is 'TestSimple' / QEMU / any other driver implementation. I'm not sure whether we want to commit this to the libvirt codebae just, since there is a fair bit more work to be done to hook up additional methods. Regards, Dan. -- |=- Red Hat, Engineering, Emerging Technologies, Boston. +1 978 392 2496 -=| |=- Perl modules: http://search.cpan.org/~danberr/ -=| |=- Projects: http://freshmeat.net/~danielpb/ -=| |=- GnuPG: 7D3B9505 F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 -=|