Bug 1687664
| Summary: | qemu-kvm: warning: cap-hpt-max-page-size lower level (16) in incoming stream than on destination (24) pops up but both source and destination have the same value 16M | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux Advanced Virtualization | Reporter: | Min Deng <mdeng> |
| Component: | qemu-kvm | Assignee: | David Gibson <dgibson> |
| Status: | CLOSED ERRATA | QA Contact: | Min Deng <mdeng> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 8.1 | CC: | ddepaula, dgibson, knoel, ngu, qzhang, rbalakri, virt-maint, xianwang, xuma, yihyu |
| Target Milestone: | rc | Flags: | knoel:
mirror+
|
| Target Release: | 8.1 | ||
| Hardware: | ppc64le | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | qemu-kvm-4.1.0-1.module+el8.1.0+3966+4a23dca1 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2019-11-06 07:13:50 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Min Deng
2019-03-12 05:22:59 UTC
I think this error could occur if you have the 3.1 qemu at the destination but the 2.12 qemu at the source end. Min, can you double check that this occurs with the fast train (3.1) qemu at *both* ends. If it does, that's definitely a bug. (In reply to David Gibson from comment #1) > I think this error could occur if you have the 3.1 qemu at the destination > but the 2.12 qemu at the source end. > > Min, can you double check that this occurs with the fast train (3.1) qemu at > *both* ends. If it does, that's definitely a bug. Hello David, Actually,the bug was initially reported on local host,it meant it only had qemu3.1 installed at both ends,what's more.I re-tested it on my host again,unfortunately,the problem still could be reproducible.So I'm afraid that it's a bug from somewhere.Could you please help to re-check ? Thanks in advance. Build information kernel-4.18.0-82.el8.ppc64le qemu-kvm-3.1.0-24.module+el8.0.1+3132+0c0fb959.ppc64le On source side, /usr/libexec/qemu-kvm -name avocado-vt-vm1 -machine pseries,max-cpu-compat=power8,cap-hpt-max-page-size=16M -nodefaults -device VGA,bus=pci.0,addr=0x2 -chardev socket,id=serial_id_serial0,path=/tmp/5,server,nowait -device spapr-vty,reg=0x30000000,chardev=serial_id_serial0 -device qemu-xhci,id=usb1,bus=pci.0,addr=0x3 -device virtio-scsi-pci,id=virtio_scsi_pci0,bus=pci.0,addr=0x4 -device scsi-hd,id=image1,drive=drive_scsi11,bus=virtio_scsi_pci0.0,channel=0,scsi-id=0,lun=0,bootindex=0 -blockdev driver=file,cache.direct=on,cache.no-flush=off,filename=rhel801-ppc64le-virtio-scsi.qcow2.compatible,node-name=drive_scsi1 -blockdev driver=qcow2,node-name=drive_scsi11,file=drive_scsi1 -m 20G,slots=256,maxmem=2T -mem-path /mnt/hugepages1G -smp 2,maxcpus=2,cores=1,threads=1,sockets=2 -device usb-tablet,id=usb-tablet1,bus=usb1.0,port=1 -vnc :35 -rtc base=utc,clock=host -enable-kvm -monitor stdio -numa node -qmp tcp:0:4446,server,nowait -object memory-backend-file,id=mem1,size=5G,mem-path=/mnt/hugepages1G -device pc-dimm,id=dimm1,memdev=mem1 -device virtio-net-pci,mac=9a:4c:4d:4e:4f:60,id=idtniYmJ,vectors=4,netdev=idG7NvsN,bus=pci.0,addr=0x5 -netdev tap,id=idG7NvsN,vhost=on,script=/etc/qemu-ifup,downscript=/etc/qemu-ifdown -incoming tcp:0:1212 QEMU 3.1.0 monitor - type 'help' for more information (qemu) qemu-kvm: warning: cap-hpt-max-page-size lower level (16) in incoming stream than on destination (24) I've reproduced the problem, investigating... Problem also exists in upstream. I've located the problem: the maxpagesize property was accidentally omitted from the migration stream. I've written a draft fix upstream. Draft fix had a problem, but Greg Kurz has posted a fix for that, now pending upstream. Fix is now merged upstream for qemu-4.1, so we'll get it in fast train for RHEL-AV-8.1. This is essentially cosmetic, so I don't believe there's any point trying to backport the fix to slow train. (In reply to David Gibson from comment #7) > Fix is now merged upstream for qemu-4.1, so we'll get it in fast train for > RHEL-AV-8.1. > > This is essentially cosmetic, so I don't believe there's any point trying to > backport the fix to slow train. Thanks David. Would you add Internal Target Release filed too? Verified the bug on the follow build qemu-kvm-4.1.0-1.module+el8.1.0+3966+4a23dca1.ppc64le The original issue has been fixed,thanks. Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2019:3723 |