qemu:///embed and isolation from global components

[Michal Prívozník]

On 18. 3. 2020 16:47, Andrea Bolognani wrote:
> On Mon, 2020-03-09 at 18:04 +0000, Daniel P. Berrangé wrote:
>> At a high level the embedded QEMU driver
>>
>>  - Isolated from any other instance of the QEMU driver
> 
> Replying here because it looks as good a place as any.
> 
> Now that Michal has made it so that identically-name domains defined
> under different qemu:///embed roots no longer clash at the machined
> level (thanks!), I have immediately bumped into the next issue: 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.

> 
> which obviously breaks everything.
> 
> In this case, is the application expected to set
> 
>   hugetlbfs_mount = "/dev/hugepages/$random"
> 
>   memory_backing_dir = "/dev/shm/$random"
> 
> in qemu.conf beforehand (I'm not sure the former setting would even
> work), or should libvirt take care of it automatically in a similar
> way it now does for machine names?
> 

The latter is true.

Michal