Hi, during my sampling overhaul effort I faced various times a mismatch between what the libvirt-python API offers for bulk stats and what VDSM needs. The return value of bulk stats is a something like [(dom1, {dict_of_bulk_stats1}), {dom2, {dict_of_bulk_stats2}), ...] While VDSM almost all the times really wants to use { dom_uuid_1: dict_of_bulk_stats_1, dom_uuid_2: dict_of_bulk_stats_2 } translation is trivial to be coded, but bulk stats retrieval is quite always in the hot path. Moreover, this is just wasteful. But in general, there will always be a not-perfect match from libvirt-python and VDSM needs. This is expected: libvirt-python needs to be more generic. So, I coded a Proof of Concept extension module which *complements* and not *replaces* the libvirt-python API. https://github.com/mojaves/libvirt-python-ovirt It monkeys-patch some APIs and replace them with VDSM-crafted ones. If we have enough of monkey patching, it is even easier to just add new APIs instead of replacing them. It was a nice and fun hack, but now, the question is: is that a concept worth developing further? Do we want to use and depend on this module? I believe that with such a buffer we can gain some agility with respect to libvirt plans and needs, and the maintainership cost _seems_ fairly low. Thoughts welcome. -- Francesco Romani RedHat Engineering Virtualization R & D Phone: 8261328 IRC: fromani