[libvirt] [PATCH 3/3] qemuBuildMemoryBackendStr: Report backend requirement more appropriately

[Jiri Denemark]

On Thu, Feb 12, 2015 at 18:03:53 +0100, Michal Privoznik wrote:
> So, when building the '-numa' command line, the
> qemuBuildMemoryBackendStr() function does quite a lot of checks to
> chose the best backend, or to check if one is in fact needed. However,
> it returned that backend is needed even for this little fella:
> 
>   <numatune>
>     <memory mode="strict" nodeset="0,2" />
>   </numatune>
> 
> This can be guaranteed via CGroups entirely, there's no need to use
> memory-backend-ram to let qemu know where to get memory from. Well, as
> long as there's no <memnode/> element, which explicitly requires the
> backend. Long story short, we wouldn't have to care, as qemu works
> either way. However, the problem is migration (as always). Previously,
> libvirt would have started qemu with:
> 
>   -numa node,memory=X
> 
> in this case and restricted memory placement in CGroups. Today, libvirt
> creates more complicated command line:
> 
>   -object memory-backend-ram,id=ram-node0,size=X
>   -numa node,memdev=ram-node0
> 
> Again, one wouldn't find anything wrong with these two approaches.
> Both work just fine. Unless you try to migrated from the older libvirt

s/migrated/migrate/

> into the newer one. These two approaches are, unfortunately, not
> compatible. My suggestion is, in order to allow users to migrate, lets
> use the older approach for as long as the newer one is not needed.
> 
> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
...
> diff --git a/tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.xml b/tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.xml
> index 01bbb3d..fe7c465 100644
> --- a/tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.xml
> +++ b/tests/qemuxml2argvdata/qemuxml2argv-cputune-numatune.xml
> @@ -1,4 +1,4 @@
> -<domain type='kvm'>
> +<domain type='qemu'>
>    <name>dummy2</name>
>    <uuid>4d92ec27-9ebf-400b-ae91-20c71c647c19</uuid>
>    <memory unit='KiB'>131072</memory>

Looks like a useless change.

Jirka