Re: [libvirt] QEMU capabilities vs machine types

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?