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

On 09/26/2017 12:00 AM, Zack Cornelius wrote: 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 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