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
