qemu:///embed and isolation from global components

Andrea Bolognani abologna at redhat.com
Tue Mar 10 18:25:46 UTC 2020


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




More information about the libvir-list mailing list