On Thu, Dec 18, 2014 at 12:46:32PM +0100, Michal Privoznik wrote: > Libvirt BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1175397 > QEMU BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1170093 > > In qemu there are two interesting arguments: > > 1) -numa to create a guest NUMA node > 2) -object memory-backend-{ram,file} to tell qemu which memory > region on which host's NUMA node it should allocate the guest > memory from. > > Combining these two together we can instruct qemu to create a > guest NUMA node that is tied to a host NUMA node. And it works > just fine. However, depending on machine type used, there might > be some issued during migration when OVMF is enabled (see QEMU > BZ). While this truly is a QEMU bug, we can help avoiding it. The > problem lies within the memory backend objects somewhere. Having > said that, fix on our side consists on putting those objects on > the command line if and only if needed. For instance, while > previously we would construct this (in all ways correct) command > line: > > -object memory-backend-ram,size=256M,id=ram-node0 \ > -numa node,nodeid=0,cpus=0,memdev=ram-node0 > > now we create just: > > -numa node,nodeid=0,cpus=0,mem=256 > > because the backend object is obviously not tied to any specific > host NUMA node. > > Signed-off-by: Michal Privoznik <mprivozn@xxxxxxxxxx> > --- > src/qemu/qemu_command.c | 16 +++++++++------- > .../qemuxml2argvdata/qemuxml2argv-hugepages-pages3.args | 3 +-- > .../qemuxml2argv-numatune-memnode-no-memory.args | 3 +-- > 3 files changed, 11 insertions(+), 11 deletions(-) ACK, that looks reasonable to me. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list