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
