[libvirt] Exposing mem-path in domain XML

[Michal Privoznik]

On 09/26/2017 12:00 AM, Zack Cornelius wrote:
> ----- Original Message -----
>> From: "Michal Privoznik" <mprivozn at redhat.com>
>> To: "Zack Cornelius" <zack.cornelius at kove.net>
>> Cc: "Daniel P. Berrange" <berrange at redhat.com>, "libvir-list" <libvir-list at redhat.com>
>> Sent: Monday, September 25, 2017 9:17:10 AM
>> Subject: Re: [libvirt] Exposing mem-path in domain XML
> 
>> On 09/15/2017 03:49 PM, Zack Cornelius wrote:
>>>
> 
> Kove would only be using our integration with domains using the file
> memorybacking via the following XML, which I think simplifies the
> cases where the memory-backend-file gets used.
> 
>  <memoryBacking>
>    <source='file'/>
>    <access mode='shared'/>
>  </memoryBacking>
> 
> The Kove integration is not compatible with huge pages, so we're just
> interested in the memoryBacking source='file' case, and not the
> hugepages cases, if that simplifies things.

Not really. Consider the following domain configuration:

<domain type='kvm'>
  <name>fedora</name>
  <memory unit='KiB'>4718592</memory>
  <memoryBacking>
    <source type='file'/>
    <access mode='shared'/>
  </memoryBacking>
  <cpu mode='host-passthrough' check='none'>
    <topology sockets='1' cores='2' threads='2'/>
    <numa>
      <cell id='0' cpus='0-3' memory='4194304' unit='KiB'/>
    </numa>
  </cpu>
  <devices>
    <memory model='dimm'>
      <target>
        <size unit='KiB'>524288</size>
        <node>0</node>
      </target>
      <alias name='dimm0'/>
      <address type='dimm' slot='0'/>
    </memory>
  </devices>
</domain>

For this configuration, two memory-backend-file objects are created. The
first one is for the guest RAM (for the NUMA node), second is for the
DIMM module. While the alias for the DIMM module is exposed in the XML,
the alias for the NUMA node is missing:

-object
memory-backend-file,id=ram-node0,mem-path=/var/lib/libvirt/qemu/ram,share=yes,size=4294967296
-numa node,nodeid=0,cpus=0-3,memdev=ram-node0
-object
memory-backend-file,id=memdimm0,mem-path=/var/lib/libvirt/qemu/ram,share=yes,size=536870912
-device pc-dimm,node=0,memdev=memdimm0,id=dimm0,slot=0

This complicates things IMO. I guess what I'm saying is that we can
generate full paths including the device alias as filename, but I'm not
sure it is going to help, is it?

Alternatively, and I admit I don't know much about Kove, if libvirt
would put all the files into per-domain directories, would that be
enough for you? In the example above all the files are put into generic
path. However, if the path looked like this:

$memoryBackingDir/$domain/

You could differentiate which files belong to which domain.

Michal

> 
> With the other bugfix that defines the aliases within the XML, and
> your locally implemented idea, would the filenames then be predicable
> or readable from the XML when using memory source file in all the
> cases with memory defined in the <memory> element, memory defined as
> part of the NUMA node, and memory defined as a dimm device?

That's the point. No. There's not direct 1:1 relationship between domain
XML and qemu cmd line. I mean, in terms of objects. To fulfill the XML
libvirt may decide to add some objects, just like we see in my example.

Michal