On 03/01/2018 04:59 PM, Peter Krempa wrote: > On Thu, Mar 01, 2018 at 14:51:45 +0000, Daniel Berrange wrote: >> On Thu, Mar 01, 2018 at 03:41:00PM +0100, Peter Krempa wrote: >>> On Thu, Mar 01, 2018 at 14:34:58 +0000, Daniel Berrange wrote: >>>> On Thu, Mar 01, 2018 at 03:28:57PM +0100, Peter Krempa wrote: > > [...] > >>> I'm not saying it's a bug. I'm just pointing out that it's not really >>> useful by itself to open connection just to anything else than the VM >>> driver itself. Libvirt is a library used to manage VMs and that's the >>> main reason anybody will install it. I doubt that anybody would install >>> libvirt to manage storage or firewall, since there are way better >>> options to do so than our network/storage driver. >> >> It isn't so compelling right now, but once we split libvirtd into one >> daemon per driver, it will be more useful to use the specific URIs if >> wanting to use the secondary drivers. It will let us containerize the >> daemons separately. It will also allow the use of real networking for >> the qemu://session daemon without setuid helpers. eg virt-manager can >> connect to network:///system to setup networking, to go with its connection >> to qemu:///session. > > Well that's actually going to be pretty nice, but at this point the > connections are not really worth as much fame. Since this is the notes > file, nobody will read it once they'll be actually made useful in other > cases than the internal connections. >
What do you mean by 'made useful'? Fixing bugs in say storage driver? I don't really see what that has to do with anything because users can use storage driver through hypervisor connection already. So if storage driver is unusable, it's unusable regardless of connection URI. Michal -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
