Re: [libvirt] [Qemu-devel] Re: Supporting hypervisor specific APIs in libvirt

On 03/22/2010 03:10 PM, Daniel P. Berrange wrote: > > >> What's the feeling about this from the libvirt side of things? Is there >> interest in support hypervisor specific interfaces should we be looking >> to provide our own management interface for libvirt to consume? >> > Adding yet another library in the stack isn't really going to solve the > problem from the POV of libvirt users, but rather fork the community > effort which I imagine we'd all rather avoid. Having to tell people to > switch to a different library API to get access to a specific feature > is a short term win, but with a significant long term cost/burden. This > means we really do need to figure out how to better/fully support QEMU's > features in libvirt, removing the feature timelag pain. > I think what we need to do is find a way to more tightly integrate the QEMU and libvirt communities in such a way that when a patch was submitted against QEMU adding a new feature, we could ask that that feature was implemented in libvirt. I see two ways to do this. One would be for libvirt to have a libvirt.so and libvirt-qemu.so. The QEMU community would have to be much more heavily involved in libvirt-qemu.so and it probably suggests that libvirt-qemu.so should follow our release cycle. libvirt would have to support using either libvirt.so or libvirt-qemu.so for it's users. The alternative would be for the QEMU community to produce a libqemu.so and for libvirt.so to consume libqemu.so. The libvirt community ought to be heavily engaged in the development of libqemu.so and certainly, shared maintainership would be appropriate. A user using libvirt.so should see guests created with either libqemu.so or libvirt.so although libqemu.so would provide weaker long term compatibility guarantees (but more features).