[libvirt] the role of libvirtd

[Daniel Veillard]

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

  I'm a bit synpathetic to the suggestion though. I think libvirt API
should help run those virtualization nodes, I would not open the gate
like completely, but if we could provide all APIs needed to manage the
node on a day by day basis  then I think this is not really beyond our
scope. I think that netcf is an example of such API where we start to
add admin services for the purpose of running virtualization. Things
like rebooting or shutting down the node would fit in this, maybe
editing a drive partition too.
  HA configuration starts to be a bit stretched, I would expect this to
be set once at creation and not part of the routine maintainance, so
probably out of scope, multipath is a bit more in scope we discussed
this already.
  Basically if we take the idea of a stripped down Node used only for
virtualization, then except for operations which are first time setup
options or maintainance, I think we should try to cover the requirements
of normal operations of that node. To some extend that means we would
step on the toes of CIM, but we would stick to a subset that's sure.

Daniel


-- 
Daniel Veillard      | libxml Gnome XML XSLT toolkit  http://xmlsoft.org/
daniel at veillard.com  | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library  http://libvirt.org/