[libvirt] QEMU capabilities vs machine types

[Eduardo Habkost]

On Wed, Feb 11, 2015 at 05:09:01PM +0100, Michal Privoznik wrote:
> On 11.02.2015 16:47, Daniel P. Berrange wrote:
> > On Wed, Feb 11, 2015 at 04:31:53PM +0100, Michal Privoznik wrote:
> >>
> > 
> > There are two reasons why we query & check the supported capabilities
> > from QEMU
> > 
> >  1. There are multiple possible CLI args for the same feature and
> >     we need to choose the "best" one to use
> > 
> >  2. The feature is not supported and we want to give the caller a
> >     better error message than they'd get from QEMU
> > 
> > I'm unclear from the bug which scenario applies here.
> > 
> > If it is scenario 2 though, I'd just mark it as CANTFIX or WONTFIX,
> > as no matter what we do the user would get an error. It is not worth
> > making our capability matrix a factor of 10+ bigger just to get a
> > better error message.
> > 
> > If it is scenario 1, I think the burden is on QEMU to solve. The
> > memory-backend-{file,ram} CLI flags shouldn't be tied to guest
> > machine types, as they are backend config setup options that should
> > not impact guest ABI.
> 
> It's somewhere in between 1 and 2. Back in RHEL-7.0 days libvirt would
> have created a guest with:
> 
> -numa node,...,mem=1337
> 
> But if qemu reports it support memory-backend-ram, libvirt tries to use it:
> 
> -object memory-backend-ram,id=ram-node0,size=1337M,... \
> -numa node,...,memdev=ram-node0
> 
> This breaks migration to newer qemu which is in RHEL-7.1. If qemu would
> report the correct value, we can generate the correct command line and
> migration succeeds. However, our fault is, we are not asking the correct
> question anyway.

I understand that RHEL-7.1 QEMU is not providing enough data for libvirt
to detect this before it is too late. What I am missing here is: why
wasn't commit f309db1f4d51009bad0d32e12efc75530b66836b enough to fix
this specific case?

For reference:

commit f309db1f4d51009bad0d32e12efc75530b66836b
Author: Michal Privoznik <mprivozn at redhat.com>
Date:   Thu Dec 18 12:36:48 2014 +0100

    qemu: Create memory-backend-{ram,file} iff needed

    Libvirt BZ: https://bugzilla.redhat.com/show_bug.cgi?id=1175397
    QEMU BZ:    https://bugzilla.redhat.com/show_bug.cgi?id=1170093

    In qemu there are two interesting arguments:

    1) -numa to create a guest NUMA node
    2) -object memory-backend-{ram,file} to tell qemu which memory
    region on which host's NUMA node it should allocate the guest
    memory from.

    Combining these two together we can instruct qemu to create a
    guest NUMA node that is tied to a host NUMA node. And it works
    just fine. However, depending on machine type used, there might
    be some issued during migration when OVMF is enabled (see QEMU
    BZ). While this truly is a QEMU bug, we can help avoiding it. The
    problem lies within the memory backend objects somewhere. Having
    said that, fix on our side consists on putting those objects on
    the command line if and only if needed. For instance, while
    previously we would construct this (in all ways correct) command
    line:

        -object memory-backend-ram,size=256M,id=ram-node0 \
        -numa node,nodeid=0,cpus=0,memdev=ram-node0

    now we create just:

        -numa node,nodeid=0,cpus=0,mem=256

    because the backend object is obviously not tied to any specific
    host NUMA node.

    Signed-off-by: Michal Privoznik <mprivozn at redhat.com>

-- 
Eduardo