libvirt/tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args

LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \
/usr/bin/kvm -S -M pc -m 64 -smp 1 \
-numa node,nodeid=0,cpus=0,mem=64 \
-nographic -monitor unix:/tmp/test-monitor,server,nowait \
-no-acpi -boot c -usb -net none -serial none -parallel none
qemuBuildMemoryBackendStr: Report backend requirement more appropriately So, when building the '-numa' command line, the qemuBuildMemoryBackendStr() function does quite a lot of checks to chose the best backend, or to check if one is in fact needed. However, it returned that backend is needed even for this little fella: <numatune> <memory mode="strict" nodeset="0,2"/> </numatune> This can be guaranteed via CGroups entirely, there's no need to use memory-backend-ram to let qemu know where to get memory from. Well, as long as there's no <memnode/> element, which explicitly requires the backend. Long story short, we wouldn't have to care, as qemu works either way. However, the problem is migration (as always). Previously, libvirt would have started qemu with: -numa node,memory=X in this case and restricted memory placement in CGroups. Today, libvirt creates more complicated command line: -object memory-backend-ram,id=ram-node0,size=X -numa node,memdev=ram-node0 Again, one wouldn't find anything wrong with these two approaches. Both work just fine. Unless you try to migrated from the older libvirt into the newer one. These two approaches are, unfortunately, not compatible. My suggestion is, in order to allow users to migrate, lets use the older approach for as long as the newer one is not needed. Signed-off-by: Michal Privoznik <mprivozn@redhat.com> 2015-02-12 19:43:27 +03:00			`LC_ALL=C PATH=/bin HOME=/home/test USER=test LOGNAME=test QEMU_AUDIO_DRV=none \`
			`/usr/bin/kvm -S -M pc -m 64 -smp 1 \`
			`-numa node,nodeid=0,cpus=0,mem=64 \`
			`-nographic -monitor unix:/tmp/test-monitor,server,nowait \`
			`-no-acpi -boot c -usb -net none -serial none -parallel none`