On 08/30/2018 08:01 AM, Michal Privoznik wrote:
https://bugzilla.redhat.com/show_bug.cgi?id=1622455
If a domain is configured to use <source type='file'/> under
<memoryBacking/> we have to honour that setting and produce
-mem-path on the command line. We are not doing so if domain has
no guest NUMA nodes nor hugepages.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
---
src/qemu/qemu_command.c | 29 +++++++++++-----------
.../fd-memory-no-numa-topology.args | 1 +
2 files changed, 16 insertions(+), 14 deletions(-)
The code and result look right and a domain can boot like this, so
Reviewed-by: John Ferlan <jferlan(a)redhat.com>
John
Still, looking at the original commit series it's not exactly "clear"
whether numa mattered or not...
Commit 0857a3bf5 (news.xml) notes "Add support in numa topology...", but
commit bc6d3121a (formatdomain.html.in) doesn't mention numa. It's too
bad the added <source> wasn't a bit more detailed and let's face it the
<allocation> is seriously lacking any substance. I wonder if <source>
should also mention hypervisor specific, yadda, yadda, but more
importantly the qemu memory_backing_dir "link" so that people understand
for qemu where things get created. I also note that for my 2G guest
there was a *definite* pause when just adding the <memoryBacking>
<source type='file'/> </memoryBacking> when starting up...
In any case, hopefully you can post a followup for formatdomain
'details' - it doesn't have to be part of the bz unless you believe
doing so is "that important" (so to speak).