qemu:///embed and isolation from global components

Andrea Bolognani abologna at redhat.com
Thu Mar 19 09:21:39 UTC 2020


On Wed, 2020-03-18 at 18:01 +0100, Michal Prívozník wrote:
> On 18. 3. 2020 16:47, Andrea Bolognani wrote:
> > if I use either one of
> > 
> >   <memoryBacking>
> >     <hugepages/>
> >   </memoryBacking>
> > 
> >   <memoryBacking>
> >     <access mode='shared'/>
> >   </memoryBacking>
> > 
> > both qemu:///embed instances try to use the same paths:
> > 
> >   /dev/hugepages/libvirt/qemu/$domid-$domname/
> > 
> >   /dev/shm/libvirt/qemu/$domid-$domname/
> 
> This is because qemu driver uses virDomainDefGetShortName() to construct
> the path which is not embed driver aware. In fact, we use it on a few
> other places:
> 
> libvirt.git $ git grep -C0 virDomainDefGetShortName  -- src/qemu/ \
>  | wc -l
> 15
> 
> so we probably have more broken plaes. I will investigate and post a
> patch. Probably something among those lines that fixed machined name
> generation.

I'm not sure changing virDomainDefGetShortName() to include the embed
root hash all the time, which I assume is what you had in mind, is a
good enough solution.

That would work very well for /dev/shm and friends, but if the path
you're building is *inside* the embed root, then, you just added 15
characters to the path of any file. This wouldn't be too bad if not
for the fact that the path to a UNIX socket can only be up to 108
characters long, which is limiting enough already...

Can we make the whole thing smart enough that the embed root hash
will appear in paths that are outside of the embed root, but not in
those that are inside it?

-- 
Andrea Bolognani / Red Hat / Virtualization




More information about the libvir-list mailing list