Re: [libvirt] the role of libvirtd

On Wed, Jul 08, 2009 at 05:46:43PM +0100, Daniel P. Berrange wrote: > > This is essentially suggesting that libvirtd become a general purpose > RPC layer for all remote management tasks. At which point you have > just re-invented QPid/AMQP or CIM or any number of other general > purpose message buses. > > libvirtd has a core well defined goal: > > - Provide a remote proxy for libvirt API calls > > if you want todo anything more than that you should be considering an > alternative remote management system. We already have 2 good ones to > choose from supported with libvirt > > - QPid/AMQP, with libvirt-qpid agent + your own custom agents > - CIM, with libvirt-CIM + your own custom CIM providers > > Both of these offer other benefits besides just pluggable support > for other functionality. In particular > > - Non-blocking asynchronous RPC calls > - Assured delivery for RPC calls > - Scalable network architecture / topology > - Inter-operability with plugins written by other projects/vendors > > Furthermore, adding more plugins to libvirtd means we will never > be able to reduce its privileges to an acceptable level, because we'll > never know what capabilities the plugins may want. I understand your point -- certainly we want to use existing RPC mechanisms for libvirt and node management, not maintain our own. However, given a libvirt-qpid daemon on the node that handles RPC over QMF (for example), is there not some value in having libvirt expose a consistent API for the operations people want to do on a host regardless of whether they have directly to do with managing a virtual machine or not?

I will note that when I presented the large client with the option of QMF talking to multiple agents on the node but exposing (effectively) a single API and a single connection, they seemed much happier. So perhaps the right way to attack this is with the ovirt-qpid daemon we are currently working on.