On 26/02/2018 13:55, Igor Mammedov wrote: >>> So how about just adding a new option --mem-share to decide if that's a >>> private memory or shared memory? That seems much straightforward way > Above options are legacy (which we can't remove for compat reasons), > their replacement is 'memory-backend-file' backend which has all of > the above including 'share' property.
More precisely, we have added "-object memory-backend-file" to avoid proliferation of options related to memory. Besides unifying the cases of 1 and >1 NUMA node, using -object also has the advantage of supporting memory hotplug. You wrote "I find adding a backend for nonnuma pc RAM is roundabout way" but basically the command line says "this VM has only one NUMA node, backed by this memory object" which is a precise description of what the VM memory looks like. > So just add 'memdev' property to machine and reuse memory-backend-file > with it instead of duplicating functionality in the legacy code. That would however also have a different RAMBlock id, effectively producing the same output as "-numa node,memdev=...". I think this should be solved at the libvirt level. Libvirt should write in the migration XML cookie whether the VM is using -object or -mem-path to declare its memory, and newly-started VMs should always use -object. This won't fix the problem for VMs that are already running, but it will fix it the next time they are started. Paolo
