On Tue, Nov 07, 2017 at 03:57:45PM +0000, Daniel P. Berrange wrote:
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
That's actually on purpose, this should not happen in the code, if it did, then
it would still function normally. We should start setting id for live XML in
tests, yes. When trying to change the fact that parsing was done with _INACTIVE
even for live domains, I found out that we are changing parse flags to _INACTIVE
if the id for the domain is not set, but actually the fallout from that change
is kind of bigger than expected and I did not bother fixing it everywhere.
Dunno about Michal, though, maybe he did :)