Re: [libvirt] QEMU capabilities vs machine types

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.