On Mon, Mar 22, 2010 at 02:25:00PM -0500, Anthony Liguori wrote: > Hi, Hi Anthony, > I've mentioned this to a few folks already but I wanted to start a > proper thread. > > We're struggling in qemu with usability and one area that concerns > me is the disparity in features that are supported by qemu vs what's > implemented in libvirt. If you could come up with a list, then I would have an easier job answering, honnestly I have the feeling we spent the last 6 months filling that gap in a really fast way. > This isn't necessarily libvirt's problem if it's mission is to > provide a common hypervisor API that covers the most commonly used > features. "most commonly used" is not the point of libvirt > However, for qemu, we need an API that covers all of our features > that people can develop against. The ultimate question we need to > figure out is, should we encourage our users to always use libvirt > or should we build our own API for people (and libvirt) to consume. > > I don't think it's necessarily a big technical challenge for libvirt > to support qemu more completely. I think it amounts to introducing > a series of virQemuXXXX APIs that implement qemu specific functions. > Over time, qemu specific APIs can be deprecated in favour of more > generic virDomain APIs. But one point of libvirt is that once an API is there we don't break it. I think there is a serious divergence of approach there, instanciating API stating 'we are gonna deprecate them sooner or later' tell the application developper 'my time is more important than yours' and not really something I like to carry to the API users. The main goal of libvirt remains to provide APIs needed to unify the development of the virtualization layers. Having APIs which makes sense only for one or 2 virtualization engines is not a problem in itself, it just raises questions about the actual semantic of that API. If that semantic is sound, then I see no reason to not add it, really and we actually often do. > 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? The real question is what do you actually want to build. Most of the feedback I have seen in this thread so far are mostly request to be able to hack on a qemu instance launched via libvirt. That looks a lot more an usability problem from the KVM/QEmu developpers than a problem related to building long term applications using libvirt stack and specific QEmu feature. As Dan answered the problem seems to be the short term, when features are being developped or tested for QEmu/KVM, I think once the feature is there we do try to provide support, and more general integration in the OS framework. I actually think we are fairly fast to roll in support for most feature, snapshot being one notable exception. Maybe more hacking support is needed, i.e. some way to access the monitor or add arbitrary qemu command line in a non-supported way, the main goal being to ease the life of developpers of QEmu/KVM, but that non-supported status need to be made clear. That's runtime facilities, and somehow I feel there is a point for this, though clearly that would for example be disabled for 'enterprise' builds. Daniel -- Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/ daniel@xxxxxxxxxxxx | Rpmfind RPM search engine http://rpmfind.net/ http://veillard.com/ | virtualization library http://libvirt.org/ -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list