Re: [libvirt] Exposing mem-path in domain XML

On 07/27/2017 03:50 PM, Daniel P. Berrange wrote: > On Thu, Jul 27, 2017 at 02:11:25PM +0200, Michal Privoznik wrote: >> Dear list, >> >> there is the following bug [1] which I'm not quite sure how to grasp. So >> there is this application/infrastructure called Kove [2] that allows you >> to have memory for your application stored on a distant host in network >> and basically fetch needed region on pagefault. Now imagine that >> somebody wants to use it for backing up domain memory. However, the way >> that the tool works is it has some kernel module and then some userland >> binary that is fed with the path of the mmaped file. I don't know all >> the details, but the point is, in order to let users use this we need to >> expose the paths for mem-path for the guest memory. I know we did not >> want to do this in the past, but now it looks like we don't have a way >> around it, do we? > > We don't want to expose the concept of paths in the XML because this is > a linux specific way to configure hugepages / shared memory. So we hide > the particular path used in the internal impl of the QEMU driver, and > or via the qemu.conf global config file. I don't really want to change > that approach, particularly if the only reason is to integrate with a > closed source binary like Kove. Yep, I agree with that. However, if you read the discussion in the linked bug you'll find that they need to know what file in the memory_backing_dir (from qemu.conf) corresponds to which domain. The reported suggested using UUID based filenames, which I fear is not enough because one can have multiple <memory type='dimm'/> -s configured for their domain. But I guess we could go with: ${memory_backing_dir}/${domName} for generic memory ${memory_backing_dir}/${domName}_N for Nth <memory/>

BTW: IIUC they want predictable names because they need to create the files before spawning qemu so that they are picked by qemu instead of using temporary names.