[libvirt] [PATCH v3 4/5] qemu: Use predictable file names for memory-backend-file

[Daniel P. Berrange]

On Tue, Nov 07, 2017 at 04:51:03PM +0100, Michal Privoznik wrote:
> In some cases management application needs to allocate memory for
> qemu upfront and then just let qemu use that. Since we don't want
> to expose path for memory-backend-file anywhere in the domain
> XML, we can generate predictable paths. In this case:
> 
>   $memoryBackingDir/libvirt/qemu/$shortName/$alias
> 
> where $shortName is result of virDomainObjGetShortName().
> 

> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cpu-numa-memshared.args b/tests/qemuxml2argvdata/qemuxml2argv-cpu-numa-memshared.args
> index 5700c3413..352819429 100644
> --- a/tests/qemuxml2argvdata/qemuxml2argv-cpu-numa-memshared.args
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-cpu-numa-memshared.args
> @@ -10,10 +10,12 @@ QEMU_AUDIO_DRV=none \
>  -M pc \
>  -m 214 \
>  -smp 16,sockets=2,cores=4,threads=2 \
> --object memory-backend-file,id=ram-node0,mem-path=/var/lib/libvirt/qemu/ram,\
> +-object memory-backend-file,id=ram-node0,\
> +mem-path=/var/lib/libvirt/qemu/ram/libvirt/qemu/-1-QEMUGuest1/ram-node0,\

Heh, we're getting '-1' in all the paths here. Presumably this is because in
the test suite we've not bothered to set the 'id' field to any value.

I can't help thinking that virDomainObjGetShortName ought to return a fatal
error if 'id' is still -1, as in non-test suite code, this would be indication
of a significant screw up by someone trying to create names before the VM config
is updated to reflect running state.  This would of course mean our tests
should set 'id' to a sensible value too.

No need to fix for this patch though - just a curiosity to look at a later
date


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|