On Wed, 2020-03-11 at 09:53 +0000, Daniel P. Berrangé wrote: > On Tue, Mar 10, 2020 at 07:25:46PM +0100, Andrea Bolognani wrote: > > In your scenario, when you don't specify a scope you get the same > > one as the primary driver is using (this matches the current > > behavior): so if you are using qemu:///session, every <interface> > > will use network:///session unless you explicitly specify > > scope='system', at which point network:///system will be used; in > > the same fashion, if you're connected to qemu:///embed, the default > > for <interface>s should be network:///embed, with the possibility > > to use either network:///session (with scope='session') or, most > > likely, network:///system (with scope='system'). > > No, I'm not talking about using the same URI for the secondary > drivers, I'm talking about using the same *privilege* level. > ie, qemu:///system and a qemu:///embed running as root should > both use the privileged network/storage driver. The qemu:///session > and qemu:///embed running as non-root should both default to > the unprivileged network/storage drivers. What's the advantage of conflating URI and privilege level? It seems to me like it only makes things complicated when they could be absolutely straightforward instead. In fact, I believe libguestfs developers have long lamented the fact that it's not really possible to have qemu:///session for the root user, which is caused by the same kind of logic... It would be preferable, I think, not to introduce even more instances of it. > > > With such functionality present, it logically then also extends to > > > cover connections to daemons running in different namespaces. > > > > I'm still unclear on how this scenario, which would apparently have > > multiple eg. privileged virtnetworkd, running at the same time but in > > different network namespaces, would work. > > There would need to be some selection method, most likely a way > to explicitly specify the socket path, but this is a longish way > into the future. Got it! -- Andrea Bolognani / Red Hat / Virtualization
