7832fac qemuBuildMemoryBackendStr: Report backend requirement more appropriately

Authored and Committed by mprivozn 9 years ago
    qemuBuildMemoryBackendStr: Report backend requirement more appropriately
    
    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
    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@redhat.com>
    
        
file modified
+4 -2
file modified
+6 -0