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