Re: [libvirt] the role of libvirtd

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