qemu:///embed and isolation from global components

[Andrea Bolognani]

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