On Thu, Jan 29, 2009 at 03:12:35PM +0900, Atsushi SAKAI wrote: If you are familiar with IBM MQ Series, then you can think of AMQP as an open standard, and open source implementation providing equiv functionality. AMQP is the name of the protocol / standard. QPid is the name of the Red Hat sponsored implementation of the AMQP (there are a number of other implementations too). QMF is an object modelling framework built ontop of the QPid implementation As you know libvirt already has a remote management capability builtin via libvirtd + the remote driver. This is classic client/server, hub and spoke network model. ie, the client machine has to directly connect to every single libvirtd. Also the libvirt RPC calls are synchronous. libvirt-qpid provides an alternate remote management model, which is more scalable to large deployments. It maps every libvirt object & API into a the QMF object model. libvirt-qpid runs on every machine and talks to libvirtd and a QPid message broker. It builds a list of all objects (domains, networks, devices, etc) that libvirtd knows about, and publishes that information to the QPid message broker. It also receives API calls from the message broker, and performs the corresponding libvirt API calls. A QPid message broker is connected to multiple libvirt-qpid, and aggregates the objects published from all of them. You can connect individual QPid message brokers together, to form a large mesh network. QPid also provides store & forward queuing, and assured delivery so you can get guarentees about what happens in the event of failures of nodes/network/brokers/etc. The application that's doing management only needs a single connection to a QPid message broker, and this gives it access to the published objects from every single libvirtd/libvirt-qpid enabled machine in the mesh network. So this is far more scalable, than having the mgmt application talk directly to every libvirtd. When an application is using QPid to manage libvir,t it is not using the libvirt.so API directly - QPid exposes an API that is autogenerated from the QMF object model you define. For libvirt-qpid, the QMF object model is a pretty much 1-to-1 mapping to the libvirt API, so it should be very familiar concept to work with. Yeah, I think Iain's message there is probably only docs around so far. It is stil in a fairly early stage of development, though the oVirt project has just switched to using QPid + libvirt-qpid for all its management tasks last week, so it is starting to get some real world usage. 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 :|