[libvirt] QEMU capabilities vs machine types

[Michal Privoznik]

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.

Michal