On 03/23/2010 01:07 PM, Daniel P. Berrange wrote:
On Tue, Mar 23, 2010 at 11:06:20AM -0500, Anthony Liguori wrote:
On 03/23/2010 10:57 AM, Paul Brook wrote:
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.
Yeah, but the problem we're facing is, I want there to be an API added
to the management layer as part of the feature commit in qemu. If there
has to be a discussion and decisions about how to model the API, it's
not going to be successful.
I thought the monitor protocol *was* our API. If not, why not?
It is. But our API is missing key components like guest enumeration.
So the fundamental topic here is, do we introduce these missing
components to allow people to build directly to our interface or do we
make use of the functionality that libvirt already provides if they can
plumb our API directly to users.
There's two levels of API here
- VM level API - essentially APIs for the QMP protocol& qdev ARGV format
- Host level API - guest enumeration, integration with other OS services
like cgroups, selinux, etc
QEMU has historically only cared about the per-VM level, but has not
actually provided any formal library APIs even for the monitor protocol
or command line syntax.
We also provide an API for guest creation (the qemu command line). When
we create a guest, we don't integrate with things like cgroups and
selinux and we probably never will. This is a place where libvirt adds
value.
The fundamental problem we have is that once you create a qemu instance,
you cannot find it from a third party tool. That's a problem we ought
to solve and I'd like to see that be common across qemu and libvirt. I
don't see that as us growing our scope into libvirt's space.
I think libvirt does two things. It provides a generic interface to
hypervisors and if people write to this interface, they get better
portability and the ability to management many platforms. It also
provides a certain amount of host services management that can include
things not directly related to qemu (like network management) and
services that further connect qemu to host services (like selinux
labelling).
What I would like to see is that a user can write to the libvirt API and
then call out to qemu specific functions when necessary. I'd also like
a user be able to interact directly with qemu without using the libvirt
generic API. The user should be able to still see the VMs and
ultimately interact with them through libvirt. The user should be able
to use libvirt to deal with host services too (like storage and network
pools).
The key is not to have two mutual exclusive management mechanisms but a
set of complementary APIs. The biggest obstacle I see is libvirt's
remote management interface. I think it's addressable though. For
instance, if libqemu.so provided a QMP IO interface, libvirt-qemu could
basically provide an interface to create that context and otherwise have
users use the libqemu.so interfaces directly.
IOW, libqemu.so would provide interfaces that looked like:
QMPContext *qemu_connect_by_name(const char *name);
int qemu_pci_add(QMPContext *ctxt, ...);
And libvirt would provide interfaces that looked like:
virQemuPtr *virDomainGetQemuPtr(virDomainPtr *ptr);
QMPContext *virQemuCreateQMPContext(virQemuPtr *ptr);
With respect to keep tracking of which operations are done through qemu,
we should discuss the technical challenges of this and figure out how we
can solve them.
The libqmp.so& libqdev.so could then be used both directly against a single
QEMU process spawned manually, but also indirectly via libvirt.
That's not quite what I'm looking for because then it's really two
separate interfaces. I'd rather see complementary interfaces much like
how Cairo integrates with GTK/GDK or even how GDK integrates with X11.
Regards,
Anthony Liguori
