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
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list