Re: [libvirt] the role of libvirtd

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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

[Index of Archives]     [Virt Tools]     [Libvirt Users]     [Lib OS Info]     [Fedora Users]     [Fedora Desktop]     [Fedora SELinux]     [Big List of Linux Books]     [Yosemite News]     [KDE Users]     [Fedora Tools]