qemu:///embed and isolation from global components

Michal Privoznik mprivozn at redhat.com
Mon Mar 9 13:02:13 UTC 2020


On 3/6/20 6:49 PM, Daniel P. Berrangé wrote:
> On Fri, Mar 06, 2020 at 06:24:15PM +0100, Andrea Bolognani wrote:
>> Recently I've been working on integrating qemu:///embed into an
>> application. It's been reasonably smooth so far :)
>>
>> There's one thing, however, that has caused a bit of confusion, and
>> I would like to clarify whether my expectations are incorrect, there
>> are genuine bugs in the implementation that need to be addressed, or
>> maybe the experimental nature of embedded driver support results in
>> not all scenarios having yet been considered and catered for.
>>
>> Using virt-qemu-run as an example, when I run it as root I see that
>>
>>    * the domain doesn't show up in the output of 'virsh list' for
>>      qemu:///system;
> 
> This is good.
> 
>>    * it does, however, show up in the output of 'machinectl', with
>>      class=vm and service=libvirt-qemu;
> 
> This is bad. It is one of the gaps we need to deal with.
> 
> A long while back I proposed a domain XML option for this:
> 
>    https://www.redhat.com/archives/libvir-list/2017-December/msg00729.html
> 
>      <resource register="none|direct|machined|systemd"/>
> 
> The "none" case meant inherit the cgroups placement of the parent
> libvirtd (or now the app using the embedded driver), and would be
> a reasonable default for the embedded case.
> 
> For the other cases, we certainly need to do something to ensure
> uniqueness. This is possibly as simple as including a fixed
> prefix like "qemu-$PID" where $PID is the app embedding the
> driver. That said, we support closing the app, and re-starting
> using the same embedded driver directory, which would change
> PID.

Instead of PID we can derive the value from the root path, e.g. i-node 
of the root dir or some substring of the path hash, say first 6 letters 
of md5($root_path). This would guarantee the stability of the prefix 
across app restarts (if we assume all root dirs to be on one FS so we 
don't have clashing i-node numbers).

Michal




More information about the libvir-list mailing list