Bug 754896

Summary: Wrong input in qmp get wrong feed back for "query-*"
Product: Red Hat Enterprise Linux 6 Reporter: Joy Pu <ypu>
Component: qemu-kvmAssignee: Virtualization Maintenance <virt-maint>
Status: CLOSED WONTFIX QA Contact: Virtualization Bugs <virt-bugs>
Severity: low Docs Contact:
Priority: low    
Version: 6.2CC: acathrow, bsarathy, lcapitulino, mkenneth, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-11-18 12:00:09 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Joy Pu 2011-11-18 05:48:34 UTC 
Description of problem:
Feed back of wrong qmp input with query-* is always not including "query-" in RHEL6.2 host, for example:

{"execute": "query-a"}
{"error": {"class": "CommandNotFound", "desc": "The command a has not been found", "data": {"name": "a"}}}

{"execute": "query-"}
{"error": {"class": "CommandNotFound", "desc": "The command  has not been found", "data": {"name": ""}}} 

Other wrong cmd will not has this problem.

Version-Release number of selected component (if applicable):
kernel:
2.6.32-215.el6.x86_64
qemu-kvm:
rpm -qa |grep qemu
qemu-kvm-debuginfo-0.12.1.2-2.204.el6.x86_64
qemu-img-0.12.1.2-2.204.el6.x86_64
qemu-kvm-tools-0.12.1.2-2.204.el6.x86_64
gpxe-roms-qemu-0.9.7-6.7.el6.noarch
qemu-kvm-0.12.1.2-2.204.el6.x86_64


How reproducible:
Always

Steps to Reproduce:
1. Start a guest with qmp monitor
2. Input some wrong monitor cmd start with "query-" like this:
{"execute": "qmp_capabilities"}
{"execute": "query-a"}
  
Actual results:
The name in data of wrong cmd feed back is missing "query-".

Expected results:
The name in data of wrong cmd feed back should including all the cmd of input.

Additional info:
Comment 2 Luiz Capitulino 2011-11-18 12:00:09 UTC 
The bug does exist, but it's very minor and I have no reports that it causes any impact to the stack. It's also fixed upstream, which means that it won't exist in rhel7.

Closing as WONTFIX, as I don't plan fixing this for rhel6.x.