Re: qemu:///embed and isolation from global components

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.

> > 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.