Bug 1304945

Summary: Tcp option of socket backend should be added for chardev-add from QMP
Product: Red Hat Enterprise Linux 7 Reporter: Min Deng <mdeng>
Component: qemu-kvm-rhevAssignee: Amit Shah <amit.shah>
Status: CLOSED NOTABUG QA Contact: Virtualization Bugs <virt-bugs>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 7.3CC: armbru, juzhang, knoel, mdeng, virt-maint
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-02-23 07:19:03 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:

Description Min Deng 2016-02-05 03:15:00 UTC
Description of problem:
Support of tcp option should be added for chardev-add from QMP

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.3.0-31.el7.x86_64

How reproducible:
more than 10 times

Steps to Reproduce:
1.boot up a guest and try to add a chardev with socket backend with *tcp* option
2.
3.

Actual results:
The chardev can not be added to guest.


Expected results:
QE have this command for socket backend with *unix* option and it works well

{"execute":"chardev-
add","arguments":{"id":"channel0","backend":{"type":"socket","data":{"addr":
{"type":"unix", "data": {"path": "/tmp/mm"}}}}}}

Additional info:
There's no useful information in QE's hand for this cmd even if QE checking source code or ask it for Libvirt QE.So please have a look.Many thanks!

Comment 2 Min Deng 2016-02-16 07:03:55 UTC
Hi Developer,
   Research the issue again,this command should work 
   {"execute":"chardev-add","arguments":{"id":"charserial1","backend":{"type":"socket","data":{"addr":{"type":"inet","data":{"host":"0.0.0.0","port":"2445"}},"wait":false,"telnet":false,"server": true}}}} 
   But we always use *tcp* option but not *inet*.
Best Regards,
Min Deng

Comment 4 Markus Armbruster 2016-02-17 18:42:09 UTC
Your bug report lacks a reproducer.  Without one, I'm reduced to guessing.  Guessing makes me grumpy.

I'm guessing you're trying to use the command from comment#2, except with "type": "tcp" instead of "type": "inet".  That's rejected with a fairly clear error message:

    {"error": {"class": "GenericError", "desc": "Invalid parameter 'tcp'"}}

Valid address types are "inet" (address family AF_INET or AF_INET6), "unix" (address family AF_UNIX), and "fd" (a file descriptor received with getfd).  The command given in comment#2 is a valid example of type "inet".

If my guess is correct, you've since found out how this thing works, and your bug can be closed NOTABUG.

If it isn't, please provide a reproducer.  Stick to the template step 1, 2, 3, actual results, expected results.  Give actual commands and actual output, not vague descriptions.  Thanks.

Comment 5 Min Deng 2016-02-23 07:19:03 UTC
(In reply to Markus Armbruster from comment #4)
> Your bug report lacks a reproducer.  Without one, I'm reduced to guessing. 
> Guessing makes me grumpy.
> 
> I'm guessing you're trying to use the command from comment#2, except with
> "type": "tcp" instead of "type": "inet".  That's rejected with a fairly
> clear error message:
> 
>     {"error": {"class": "GenericError", "desc": "Invalid parameter 'tcp'"}}
> 
> Valid address types are "inet" (address family AF_INET or AF_INET6), "unix"
> (address family AF_UNIX), and "fd" (a file descriptor received with getfd). 
> The command given in comment#2 is a valid example of type "inet".
> 
> If my guess is correct, you've since found out how this thing works, and
> your bug can be closed NOTABUG.
> 
> If it isn't, please provide a reproducer.  Stick to the template step 1, 2,
> 3, actual results, expected results.  Give actual commands and actual
> output, not vague descriptions.  Thanks.

  Thanks for your detail reply and the issues has been resolved,so close it.