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