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? Slings, arrows, or thunderous applause welcome... Take care, --Hugh -- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list