On two separate occasions I have had the opportunity to enable a new QEMU API in libvirt. The first API is a memory statistics reporting interface that can be useful for managing guest memory ballooning. (For the curious, this is virDomainMemoryStats in libvirt and ‘info balloon’ in qemu). The second, a work-in-progress, is a mechanism for locally populating a disk image from a backing image. (See the libvirt list). These experiences have shown me that there is definitely room for improvement in the way we approach libvirt-qemu interoperability.
I believe the problem stems from differences in the way libvirt and qemu view the virtualization ecosystem. (Disclaimer: I do not pretend to speak for everyone, these are my observations). Qemu/kvm developers are narrowly focused on solving problems with and adding features to qemu. They do not think about libvirt or other hypervisors too much and therefore APIs get added to qemu that are not hypervisor agnostic and that do not easily mesh with the libvirt model.
The libvirt community has developed an API that rides above the hypervisor level and aims to be as neutral as possible by creating abstractions where necessary. The primary focus is on end-user consumability of the libvirt interfaces with less regard to the underlying hypervisor implementations.
This dynamic has created two separate communities that are intently focused on their specific domains with a neglected gap between the two. As a consequence, the process for adding a new function to qemu and libvirt is something like this:
- Work in the qemu community to get a new feature and monitor commands upstream.
- Present the qemu API to the libvirt community with a strawman implementation.
- Negotiate changes to the API to make it fit into the libvirt model.
- Work those changes back into qemu.
- Repeat 3 & 4 until differences are resolved.
- Work in the libvirt community on a set of patches to implement the approved API.
The back and forth nature of the current situation is the fault of neither libvirt or qemu. It just means we are not talking soon enough. To solve this problem as a joint community we should try to build early communication into our processes. Before code is committed into either qemu or libvirt we ask: “Will this code require changes or extensions to the API between qemu and libvirt?” If so, a discussion on the matter should be had first and an agreement on the API reached prior to adding the feature. The agreed-upon API should be kept up to date in a specification document similar to that used for the virtio specification.
By talking about APIs earlier in the development process, we can bring the libvirt and qemu communities closer together, avoid wasting time on reimplementing features, spend less time reviewing multiple patch submissions, and provide the best experience for our users.