Bug 1089610

It might not a regression since I tried qemu-kvm-1.5.3-40.el7.x86_64 and qemu-kvm-1.5.3-10.el7.x86_64, also hit this issue. Any further testing, let me know.

vram sizes which are not a power of two are not valid (both RHEL 6+7).
qxl will silently round up the sizes to the next power of two.

vram sizes smaller than 16M are not valid in RHEL-6.  If you ask for smaller vram sizes RHEL-6 will silently use 16M instead.  in RHEL-7 this is relaxed and you can ask for vram sizes as small as a single page (4k).

So the root cause is that rhel6 uses a 16M vram bar whereas rhel7 uses a 8M vram bar with the specified command line, and the size mismatch leads to the migration error.

I'd suggest to adapt the test matrix to the actual rhel6 capabilities and drop the tests with vram sizes smaller than 16M.

Sounds ok?

(In reply to Gerd Hoffmann from comment #3)
> vram sizes which are not a power of two are not valid (both RHEL 6+7).
> qxl will silently round up the sizes to the next power of two.
> 
> vram sizes smaller than 16M are not valid in RHEL-6.  If you ask for smaller
> vram sizes RHEL-6 will silently use 16M instead.  in RHEL-7 this is relaxed
> and you can ask for vram sizes as small as a single page (4k).
> 
> So the root cause is that rhel6 uses a 16M vram bar whereas rhel7 uses a 8M
> vram bar with the specified command line, and the size mismatch leads to the
> migration error.
> 
> I'd suggest to adapt the test matrix to the actual rhel6 capabilities and
> drop the tests with vram sizes smaller than 16M.
> 
> Sounds ok?

Hi Gerd,

From QE POV, it's ok if we can make sure the real customer can not hit this issue.

Hi Huding,

Can you have a try migration again with vram=16M since gerd mentioned that this is limitation value. 

If works, we could test with vram>=16M in the feature.

Best Regards,
Junyi

> Hi Huding,
> 
> Can you have a try migration again with vram=16M since gerd mentioned that
> this is limitation value. 
> 
> If works, we could test with vram>=16M in the feature.
> 

I test vram=16M and the result is that the migration of rhel6.5-64 guest from rhel6.5 host to rhel7.0 host is successful. The command line is as following:

/usr/libexec/qemu-kvm -M rhel6.5.0 -cpu Westmere,hv_relaxed -enable-kvm  -m 4096 -smp 4,sockets=2,cores=2,threads=1,maxcpus=160 -k en-us -drive file=/mnt/RHEL-Server-6.5-64-virtio.q=none,id=drive-virtio-disk,format=qcow2,cache=none,aio=native,werror=stop,rerror=stop,media=disk,snapshot=off,bus=1,unit=1 -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk,id=virtio-disk,bus=pci.0,addr=0x7,bootindex=1 -monitor stdio -serial unix:/tmp/monitor,server,nowait -net none -vnc :1 -vga qxl -global qxl-vga.vram_size=16777216

> From QE POV, it's ok if we can make sure the real customer can not hit this
> issue.

The only sensible thing I can see is document it.

The problem is in the old RHEL-6 version, not RHEL-7.  And trying to fix it in RHEL-6.6 (by making it behave like RHEL-7) will not really fix the fundamental underlying issue.  6.6 -> 7 migration will work then, but 6.5 -> 6.6 will break instead ...

(In reply to Gerd Hoffmann from comment #6)
> > From QE POV, it's ok if we can make sure the real customer can not hit this
> > issue.
> 
> The only sensible thing I can see is document it.
> 
> The problem is in the old RHEL-6 version, not RHEL-7.  And trying to fix it
> in RHEL-6.6 (by making it behave like RHEL-7) will not really fix the
> fundamental underlying issue.  6.6 -> 7 migration will work then, but 6.5 ->
> 6.6 will break instead ...

Thanks for the explanation. Yes it is. Document it in release notes or some place else seems reasonable.

Best Regards,
Junyi

We could do with adding some more diagnostics to the RAM loading so that the error was more obviously QXL related; at the moment arch_init.c:ram_load just spits -EINVAL in the case of mismatched block lengths, it could easily print the block name and the two lengths and a message saying they didn't match.

Added doc text.

I think we could have added a property "min_vram_size" to RHEL7, and forced it to 16MB in the RHEL6 machine types.  However, changing the RHEL6 machine types after the 7.0 release would probably cause more trouble than benefit.