[libvirt] Question about libvirt-qpid

[Daniel P. Berrange]

On Thu, Jan 29, 2009 at 03:12:35PM +0900, Atsushi SAKAI wrote:
> 2 questions.
> 
> 
> 1)Would you explain the use case for libvirt-qpid?
>   Which case AMDQ messaging is good for.
>   If I am missing some document, Please point me.
>   By the way I am reading through following document.
>   http://jira.amqp.org/confluence/download/attachments/2523279/amqp-model-draft101.pdf
>   I guess this is fit for huge data case?

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.

> 2)Where is the document about set up libvirt-qpid?
> There is not in package document.
> Only in mailing list, it should goes some document.
> https://www.redhat.com/archives/libvir-list/2008-September/msg00388.html

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 :|