Bug 1116315
Summary: | fail to execute the 'memsave' QMP command in qemu-kvm-rhev-2.0.0 | ||
---|---|---|---|
Product: | Red Hat Enterprise Linux 7 | Reporter: | chcheng <chcheng> |
Component: | qemu-kvm-rhev | Assignee: | Cole Robinson <crobinso> |
Status: | CLOSED WONTFIX | QA Contact: | Virtualization Bugs <virt-bugs> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 7.0 | CC: | armbru, chayang, coli, hhuang, juzhang, knoel, michen, qzhang, rbalakri, virt-maint |
Target Milestone: | rc | Keywords: | Regression |
Target Release: | 7.0 | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2015-08-31 21:18:08 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
chcheng
2014-07-04 08:36:11 UTC
Limit the group to Red Hat Employee (internal) since qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64 is internal test build. Can you provide a full qemu command line that reproduces? This doesn't trivially reproduce for me at least (In reply to Cole Robinson from comment #5) > Can you provide a full qemu command line that reproduces? This doesn't > trivially reproduce for me at least Hi Cole Robinson, My qemu-kvm cmdline is as following. # /usr/libexec/qemu-kvm -M pc -cpu host -enable-kvm -m 2048 -smp 2,sockets=2,cores=1,threads=1 -no-kvm-pit-reinjection -usb -device usb-tablet,id=input0 -name chcheng -uuid 990ea161-6b67-47b2-b803-19fb01d30d30 -rtc base=localtime,clock=host,driftfix=slew -device virtio-serial-pci,id=virtio-serial0,max_ports=16,vectors=0,bus=pci.0,addr=0x3 -chardev socket,id=channel1,path=/tmp/helloworld1,server,nowait -device virtserialport,chardev=channel1,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port1 -chardev socket,id=channel2,path=/tmp/helloworld2,server,nowait -device virtserialport,chardev=channel2,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port2 -netdev tap,id=hostnet0,vhost=on,script=/etc/qemu-ifup -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,bus=pci.0,addr=0x5,bootindex=2 -device virtio-balloon-pci,id=ballooning,bus=pci.0,addr=0x6 -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -k en-us -boot menu=on -qmp tcp:0:4444,server,nowait -serial unix:/tmp/ttyS0,server,nowait -vnc :2 -spice disable-ticketing,port=5931 -monitor stdio -drive file=/home/cccc.2,if=none,id=drive-virtio0-0-0,media=disk,werror=stop,rerror=stop,cache=none,format=qcow2 -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio0-0-0,id=virtio0-0-0,bootindex=0 QMP: {"execute": "qmp_capabilities"} {"return": {}} {"execute":"memsave","arguments":{"val":1,"size":655350000,"filename":"aaaa"}} {"error": {"class": "GenericError", "desc": "Invalid addr 0x0000000000000001specified"}} host info: # uname -r && rpm -q qemu-kvm-rhev 3.10.0-126.el7.x86_64 qemu-kvm-rhev-2.0.0-2.el7ev.test.x86_64 guest info: # uname -r 3.10.0-126.el7.x86_64 Best Regards, chcheng Okay, I can reproduce. Using this more stripped down command line: ./x86_64-softmmu/qemu-system-x86_64 -m 2048 \ -smp 2,sockets=2,cores=1,threads=1 \ -netdev user,id=hostnet0 \ -device virtio-net-pci,netdev=hostnet0,id=virtio-net-pci0,mac=00:01:02:B6:40:21,bus=pci.0,addr=0x5,bootindex=2 \ -drive file=/mnt/data/devel/images/f20.qcow2,if=none,id=drive-virtio0-0-0,media=disk,werror=stop,rerror=stop,cache=none,format=qcow2 \ -device virtio-blk-pci,bus=pci.0,addr=0x7,drive=drive-virtio0-0-0,id=virtio0-0-0,bootindex=0 \ -display none \ -monitor stdio And this monitor command: memsave 0 655350000 aaaa You need to wait for the guest to actually leave the bios and start booting before the failure pops up. The error message was added with this commit: commit 2f4d0f5990ede025720e41fa473029e9ca85e8b8 Author: Aneesh Kumar K.V <aneesh.kumar.ibm.com> Date: Tue Oct 1 21:49:30 2013 +0530 target-ppc: Check for error on address translation in memsave command When we translate the virtual address to physical check for error. Which seems reasonable. The API is only exposed as virDomainMemoryPeek by libvirt, however none of the desktop tools use that, nor vdsm, and I don't think openstack does either. And the thing is, I don't really know how memsave is expected to be used, or even how to verify that it's output is 'working'. So I don't know how to tell if the error message is a legitimate error condition, or something that can be worked around. chcheng, is this part of a qe test suite? do you just check to see that the API succeeds, or is the memory output analyzed in any way? Should have also mentioned, I reproduce with qemu.git as well (In reply to Cole Robinson from comment #7) > > The API is only exposed as virDomainMemoryPeek by libvirt, however none of > the desktop tools use that, nor vdsm, and I don't think openstack does > either. > > And the thing is, I don't really know how memsave is expected to be used, or > even how to verify that it's output is 'working'. So I don't know how to > tell if the error message is a legitimate error condition, or something that > can be worked around. > chcheng is on leave, so i help to reply her needinfo. > chcheng, is this part of a qe test suite? do you just check to see that the > API succeeds, or is the memory output analyzed in any way? Right, we have such test scenario/plan reviewed by QMP feature developer and we just check the QMP API to make sure it succeeds, not concerned about the memory output analyzed from KVM QE view. Please correct me if any mistake, thanks in advance. Best Regards, sluo Since this isn't actually required by RHEV or any common usages of libvirt, it's really only affecting an arbitrary QE test case, and it's not obvious to me if qemu is even wrong in erroring here, I don't think this should be a 7.1 blocker. Deferring to 7.2 (In reply to Cole Robinson from comment #11) > Since this isn't actually required by RHEV or any common usages of libvirt, > it's really only affecting an arbitrary QE test case, and it's not obvious > to me if qemu is even wrong in erroring here, I don't think this should be a > 7.1 blocker. Deferring to 7.2 Same still applies. Given that none of the tools even need this functionality I think we can safely close this for RHEL7, but since I don't really understand the underlying issue maybe it's just another bug lying in wait. Dunno... Too late for 7.2, move to 7.3. Cole, If you can reproduce it, maybe you should just fix it upstream and we'll get it on the next rebase. Or, if you really don't think it is important, then just close it. Thanks! (In reply to Karen Noel from comment #16) > > Cole, If you can reproduce it, maybe you should just fix it upstream and > we'll get it on the next rebase. > > Or, if you really don't think it is important, then just close it. Thanks! Comment #7 still applies... I don't know enough about this space to know if the 'regression' here is even an error or not, it seems plausible it's intentional. But since no higher level tools actually need this function to work, let's just close this Re comment#7: the upstream commit message quoted there is annoyingly misleading. 1. This isn't about target-ppc. It's perfectly generic code. All targets are affected. 2. This isn't about translating virtual address to physical. The command saves *physical* memory, as seen by a specific CPU, by default cpu 0. One error per phrase, promising contestant for the "confuser of the week" contest. Can't say why memsave's idea of the CPU's physical memory changes during boot. Correction: I got confused. The command to save physical memory is pmemsave. memsave saves virtual memory. So the error is indeed about virtual-to-physical address translation, and the fact that it changes during boot is not surprising. |