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