On 11/14/2017 06:26 PM, Daniel P. Berrange wrote: > The solution(s) > =============== > > As noted above, we made some baby-steps towards a modular daemon architecture > when we introduced virtlockd and virlogd. It is now time to fully commit to a > modular design and explode libvirtd into a swarm of daemons each responsible for > a clearly demarked task. Such a decomposition would naturally fall across the > internal driver boundaries, giving a virtnwfilterd, virtnetworkd, virtstoraged, > virtnodedevd, etc. We have to maintain compatibility with our existing client > API implementation though. This libvirtd would have to still accept connections > from the client and route the RPC request directly onto the modular daemon. We > could also enhance the client API to directly know how to connect to the modular > daemons, bypassing libvirtd. If we restricted the modular daemons to only concern > themselves with local UNIX domain socket usage, we could then provide libvirtd > as the bridge to remote TCP access, and for backcompat with legacy client library > impls. > > [app] -> [libvirt.so] -> [libvirtd] > > becomes > > [app] -> [libvirt.so] -> [virthypervisord] > +> [virtnetworkd] > +> [virtstoraged] > ...etc > So what about remote connections? Say hostA is running my KVMs and hostB is where mgmt app lives. If hostB is connecting to hostA's libvirt I guess it's still going to be libvirtd which will then multiplex RPC calls and redirect them to correct daemon? IOW, if hostB calls virStoragePoolGetXMLDesc() how is this request going to end up at hostA's virstoraged? Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
