Re: qemu:///embed and isolation from global components
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