Bug 1352799

Summary: Client information from hmp doesn't vanish after client disconnect when using vnc display
Product: Red Hat Enterprise Linux 7 Reporter: Guo, Zhiyi <zhguo>
Component: qemu-kvm-rhevAssignee: Gerd Hoffmann <kraxel>
Status: CLOSED ERRATA QA Contact: Guo, Zhiyi <zhguo>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 7.3CC: chayang, juzhang, knoel, michen, mrezanin, virt-maint, xfu
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: All   
Fixed In Version: qemu-kvm-rhev-2.6.0-21.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2016-11-07 21:20:54 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 Guo, Zhiyi 2016-07-05 06:12:26 UTC
Description of problem:
Client info doesn't vanish after client disconnect when using vnc display

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.Use vnc with cmd: # /usr/libexec/qemu-kvm -vnc :0 -monitor stdio -qmp tcp:localhost:4444,server,nowait

2.Connect vnc display from local:
# vncviewer -Shared &
And query vnc client info from hmp:
{ "execute": "query-vnc" }

3.Establish another connection to vnc display from local:
# vncviewer &
Client from step 2 is disconnected and query vnc client info again from hmp:
{ "execute": "query-vnc" }

Actual results:
After step 3, both vnc clients info can be queried from hmp:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "57104", "host": "", "websocket": false}, {"family": "ipv4", "service": "57100", "host": "", "websocket": false}], "service": "5900", "host": ""}}

Expected results:
After step 3, only client info from step 3 exists and can be queried from hmp, this should like:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "57104", "host": "", "websocket": false}], "service": "5900", "host": ""}}

Additional info:
Try same steps on qemu-kvm-rhev-2.3.0-31.el7_2.16.x86_64, no such issue happen.
After step2, query from hmp:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "37606", "host": "", "websocket": false}], "service": "5900", "host": ""}}

After step 3, query from hmp:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "37608", "host": "", "websocket": false}], "service": "5900", "host": ""}}

Comment 2 Gerd Hoffmann 2016-07-13 10:24:06 UTC

Comment 3 Gerd Hoffmann 2016-08-11 13:15:01 UTC
patch posted.  scratch build:

Comment 4 Miroslav Rezanina 2016-08-16 11:23:01 UTC
Fix included in qemu-kvm-rhev-2.6.0-21.el7

Comment 6 Guo, Zhiyi 2016-09-14 08:06:19 UTC
Verified with qemu-kvm-rhev-2.6.0-25.el7.x86_64, after step 3, only latest vnc connection information remain:

1st vnc connect:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "40886", "host": "", "websocket": false}], "service": "5900", "host": ""}}

2nd vnc connect:
1st vnc client dropped:
{"timestamp": {"seconds": 1473839969, "microseconds": 596}, "event": "VNC_DISCONNECTED", "data": {"server": {"auth": "none", "family": "ipv4", "service": "5900", "host": "", "websocket": false}, "client": {"family": "ipv4", "service": "40886", "host": "", "websocket": false}}}

vnc connection remain:
{ "execute": "query-vnc" }
{"return": {"enabled": true, "auth": "none", "family": "ipv4", "clients": [{"family": "ipv4", "service": "40890", "host": "", "websocket": false}], "service": "5900", "host": ""}}

Comment 7 Guo, Zhiyi 2016-09-14 08:07:14 UTC
Move to verified per comment 6

Comment 9 errata-xmlrpc 2016-11-07 21:20:54 UTC
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.