On 11/07/2017 04:57 PM, 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 Yeah well, libvirt.git $ git grep "domain.*-1" tests/ | grep args | wc -l 603 I strongly vote for fixing it up separately then. Michal -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
