Consider the following part of domain XML:
<numatune>
<memory mode='static' nodeset="0,2"/>
</numatune>
<cpu>
<numa>
<cell id='0' cpus='0' memory='65536' unit='KiB'/>
</numa>
</cpu>
Yes, this have a great potential of breaking things. Especially,
this will break migration between previous two or three upstream
releases and current release we are working on, because libvirt
started domains in more complicated way (even if not needed).
After these patches, domains will be started in simpler way which
is incompatible.
On the other hand, we get backward compatibility with much more
releases than we are about to break.
Michal Privoznik (3):
numatune_conf: Expose virDomainNumatuneNodeSpecified
qemuxml2argvtest: Fake response from numad
qemuBuildMemoryBackendStr: Report backend requirement more
appropriately
src/conf/numatune_conf.c | 2 +-
src/conf/numatune_conf.h | 3 +++
src/libvirt_private.syms | 1 +
src/qemu/qemu_command.c | 6 ++++--
tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.args | 5 +++++
tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.xml | 2 +-
.../qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args | 5 +++++
tests/qemuxml2argvtest.c | 12 +++++++++++-
8 files changed, 31 insertions(+), 5 deletions(-)
create mode 100644 tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.args
create mode 100644
tests/qemuxml2argvdata/qemuxml2argv-numatune-auto-prefer.args
--
2.0.5
--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list
