Re: qemu:///embed and isolation from global components
On Tue, 2020-03-10 at 16:00 +0000, Daniel P. Berrangé wrote:
The split daemon model is intended to allow us to address this
long standing design flaw, by allowing the QEMU session driver
to optionally talk to a secondary driver running with different
privileges, instead of the instance running with the same privs.
So currently we have
<interface type='network'>
<source network='default'/>
</interface>
This refers to a secondary driver running at the same privilege
level.
I expected we'd extend it to allow
<interface type='network'>
<source scope='system' network='default'/>
</interface>
This explicitly requests the secondary driver running with elevated
privileges.
This makes perfect sense to me, and in fact I believe you're
basically suggesting what I was arguing for earlier :)
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').
virtlogd would probably have to be treated a bit differently since
it needs to be running even before the first guest is started, but
other than that the same general principle should apply.
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.
--
Andrea Bolognani / Red Hat / Virtualization