On Wed, Sep 24, 2008 at 10:55:36AM -0700, Ian Main wrote: > > So I've been working on a qpid interface to libvirt. Here's the description > I've come up with: > > libvirt-qpid provides an interface with libvirt using QMF (qpid modeling > framework) which utilizes the AMQP protocol. The Advanced Message Queuing > Protocol (AMQP) is an open standard application layer protocol providing > reliable transport of messages. > > QMF provides a modeling framework layer on top of qpid. This interface > allows you to manage hosts, domains, pools etc. as a set of objects with > properties and methods. > > The source code repo: > > http://git.et.redhat.com/?p=libvirt-qpid.git;a=summary > > So I'd like to hear any feedback you guys might have. This file in particular > describes the API that is used to interact with libvirt. > > http://git.et.redhat.com/?p=libvirt-qpid.git;a=blob_plain;f=src/libvirt-schema.xml I really like how you decided to go for a 1-to-1 mapping of libvirt C API into QMF api :-) I am still kinda undecided about the Node vs Connect root object, but I'm leaning towards your current model, or 1 libvirt-qpid agent using a specific libvirt connect URI, thus making an explicit Connect object unneccessary. If someone wants to export multiple hypervisor connections that it ought to be possible to run multiple instances of the daemon Also, if we want to have a real accurate 1-to-1 mapping, then really the Domain statistics would be better in a DomainInfo object, in the same way you've dealt with Node, vs NodeInfo objects. > My TODO list looks like this: > > - Not sure on camel case or underscores. Original libvirt API uses > camel case, I went with underscores as I was originally basing it off > the ruby bindings. Typically this is decided according to conventions of the language being bound to. Are there any established conventions by people doing QMF work ? If there are none, then I'd recommend we stick to the convention used by the libvirt C library. > - Need rc scripts, daemonization, better reconnect/error handling for > both qpid and libvirt. I think it should attempt to reconnect until > successful whenever it gets disconnected. We may need an extra status > property for this state as well. You can probably just copy the libvirtd init script & rename the daemon process in it - particularly if you follow the libvirtd argv parsing. Auto-reconnecting upon failure is a interesting idea - be good to be able to restart libvirtd, without needing to bounce the agent too > - Return libvirt error codes? (it's just text msgs right now with error > status bit). Yep, we need to include as much of the libvirt error object data as possible - merely skip the 'domain' and 'network' deprecated fields, and the 'connect' field which is irrelevant iun this context. > - Make it less chatty, but log stuff Configurable use of syslog() would be a good idea. For sake of consistency I'd recommend looking at the libvirtd daemon, and its command line arg handling - see qemud/qemud.c file and the main() method in it. Pretty much all the libvirtd argv would make sense for libvirt-qpid agent. > If you wish to try it out, I've made rpms for fedora 9 x86_64 and i386. > They are in the ovirt repo, which you can add to yum using: > > rpm -ivh http://ovirt.org/repos/ovirt/9/ovirt-release-LATEST.fc9.noarch.rpm > > Once you have that set up, 'yum install libvirt-qpid python-qpid', and then > run (each in their own terminals): > > qpidd --auth no > libvirt-qpid (as root to auth with libvirt) > qpid-tool Have you tried it out across with a network of machines all routing over a AMQP grid ? I'm interested to know how 'chatty' it is as we add lots of libvirt nodes - particularly wrt to the pushing of domain statistics on a frequent basis for lots of domains. > qpid-tool provides an interface to qpid and allows you to view/manipulate the > qpid models/objects. Here is an example of how it looks using qpid-tool: This is perhaps the bit I like most about QPID - automatically get a single point global view of the system, with a reliable messaging backbone, and strong authentication & strong typing. Daniel -- |: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :| |: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :| -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list