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.
Michal
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list
