On Wed, Jul 08, 2009 at 05:46:43PM +0100, Daniel P. Berrange wrote: > On Wed, Jul 08, 2009 at 12:10:18PM -0400, Hugh O. Brock wrote: > > Hello all. > > > > I spent quite a while yesterday in a meeting with a client interested in > > using libvirt for a large project. > > > > They are quite happy in general with the direction things are > > going. However they have objections to a couple of libvirt design points > > that have come up in multiple cases in the past, including in developing > > the other project I'm involved in, oVirt. Specifically, they would > > really prefer that libvirtd be a one-stop shop for everything they need > > to do on a virtualization host, including things we have traditionally > > held out-of-scope for libvirt. A partial list of those things would > > include: > > > > * In-depth multipath config management > > * Hardware lifecycle management (power-off, reboot, etc.) > > * HA configuration > > > > ... and pretty much anything else you might want to do on a piece of > > hardware that is hosting virtual machines. > > > > My initial reaction of course was to tell them "Well you should just > > use a separate agent for that sort of thing." But of course this means > > making a separate connection to the node depending on what operation > > you want to perform, which is cumbersome. > > > > So I guess what I'm asking is, why *not* expand the scope of libvirtd > > to be a one-stop shop for managing a node? Is there a really good > > reason it shouldn't have the remaining capabilities libvirt users > > want? Is that reason good enough to balance the headache our users > > have to deal with in coming up with a separate package to handle the > > tasks libvirtd does not? > > 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. Daniel V., any further thoughts on this? --Hugh -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list