On Wed, Feb 11, 2015 at 04:31:53PM +0100, Michal Privoznik wrote: Historically we've tried to treat the machine type as a black box or a simple "tag" which just affects some set of default settings that guest sees. That assumption has already broken down a little bit on x86 where we need to distinguish PIIX vs Q35 in order todo correct PCI device address assignment, take account of different default PCI host bridge and PATA/SATA controller layout We'll get more of that as we take non-x86 arches more seriously as their machine types show even more variance in the defautl base board layout/setup. While we might try to get QEMU to provide introspection for the machine types to query the default bus topology, I'm not convinced that it will be a tractable problem to solve with an entirely metadata driven approach. IOW I wouldn't be surprised if we end up with more machine type specific code branches in libvirt for arm, etc. There are two reasons why we query & check the supported capabilities from QEMU 1. There are multiple possible CLI args for the same feature and we need to choose the "best" one to use 2. The feature is not supported and we want to give the caller a better error message than they'd get from QEMU I'm unclear from the bug which scenario applies here. If it is scenario 2 though, I'd just mark it as CANTFIX or WONTFIX, as no matter what we do the user would get an error. It is not worth making our capability matrix a factor of 10+ bigger just to get a better error message. If it is scenario 1, I think the burden is on QEMU to solve. The memory-backend-{file,ram} CLI flags shouldn't be tied to guest machine types, as they are backend config setup options that should not impact guest ABI. 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 :|

On Wed, Feb 11, 2015 at 05:09:01PM +0100, Michal Privoznik wrote: Ah so the problem is rather than QEMU's migration data stream was not compatible for these two possible NUMA setups, despite it not affecting guest ABI. In general I'd like to think we'd not get into this situation in the first place. We'd probably have to just special case the code based on machine type in this case though 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 :|

On 12.02.2015 20:25, Eduardo Habkost wrote: The numa pinning can be expressed in libvirt in this way: <numatune> <memory mode='strict' nodeset='0-7'/> <memnode cellid='0' mode='preferred' nodeset='3'/> <memnode cellid='2' mode='strict' nodeset='1-2,5,7'/> </numatune> This tells, to pin guest #0 onto host #3, guest #2 onto host #1-2,5, or 7. For the rest of guest numa nodes, they are placed onto host #0-7. As long as there explicit guest guest numa node pinning onto host nodes (the <memnode/> element), memory-object-ram is required. However, if <numatune/> has only one child <memory/> we still can guarantee the requested configuration in CGroups and don't necessarily need memory-object-ram. My patch, you've referred to, was incomplete in this case. Moreover, it was buggy, it allowed combining use of bare -numa and memory-object-ram at the same time (which is not allowed). Michal