On 10/16/2017 11:42 PM, Zack Cornelius wrote:
> ----- Original Message -----
>> From: "Michal Privoznik" <mpriv...@redhat.com>
>> To: "Zack Cornelius" <zack.cornel...@kove.net>
>> Cc: "libvir-list" <libvir-list@redhat.com>
>> Sent: Friday, September 29, 2017 2:44:13 AM
>> Subject: Re: [libvirt] Exposing mem-path in domain XML
>
>
>> 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?
>>
>
> Looking at the examples, it seems like these automatically added
> memory-backend-file objects would always be generated in a consistent manner.
> As long as this is true, and these objects always end up with a consistent
> filenames, our integration components can assume the filenames in a
> consistent way.
>
> For instance, as long as every numa <cell> element which has memory defined
> generates a file named ram-node<numa_node_number>, we can handle that mapping
> within our integration components by parsing the XML and identifying the NUMA
> nodes with memory, and allocating an appropriate amount, with the correct
> filename.
Okay. But I just realized, if /var/lib/libvirt/qemu/ram is the
memoryBackingDir set in qemu.conf, we're in a trouble. I mean, in
general, memoryBackingDir is shared across all the domains. So, if the
first domain comes and creates/uses: $memoryBackingDir/ram0, the second
domain is going to construct the very same path and things will clash.
So what if, I'd introduce yet another config option into qemu.conf that
accepts a boolean value, say memoryBackingDirUsePredictive (very bad
name, I'm all ears for better one), and if it is enabled, libvirt
constructs the following path instead:
$memoryBackingDir/libvirt/qemu/$shortName/ramN
where $shortName is the result of virDomainObjGetShortName(), which in
99% cases is ${domainID}-${domainName}
BTW, I'm still not fully convinced this is a good idea to do so. But if
we document that the constructed path can change across the releases (if
we find ourselves in need to do so), we should be safe. So let me write
the patch and post it onto the list.
Michal
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
