Bug 1983915

Summary:	Wrong socket address in qemu while using 'tight=on'
Product:	Red Hat Enterprise Linux 9	Reporter:	liunana <nanliu>
Component:	qemu-kvm	Assignee:	Marc-Andre Lureau <marcandre.lureau>
qemu-kvm sub component:	General	QA Contact:	liunana <nanliu>
Status:	CLOSED ERRATA	Docs Contact:
Severity:	medium
Priority:	high	CC:	berrange, marcandre.lureau, mrezanin, virt-maint, yfu
Version:	9.0	Keywords:	Triaged
Target Milestone:	beta	Flags:	pm-rhel: mirror+
Target Release:	---
Hardware:	x86_64
OS:	Linux
Whiteboard:
Fixed In Version:	qemu-kvm-6.1.0-1.el9	Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:	1983684	Environment:
Last Closed:	2022-05-17 12:23:27 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:
Bug Depends On:	1997408
Bug Blocks:

Description liunana 2021-07-20 07:36:59 UTC

This bug was initially created as a copy of Bug #1983684

I am copying this bug because: 



Description of problem:
Wrong socket address in qemu while using 'tight=on'


Version-Release number of selected component (if applicable):
    4.18.0-322.el8.x86_64
    qemu-kvm-6.0.0-23.module+el8.5.0+11740+35571f13.x86_64



How reproducible: 100%


Steps to Reproduce:
1. Lanuch QEMU with cmdline:
 # /usr/libexec/qemu-kvm -monitor stdio -chardev socket,id=channel0,path=/tmp/port0,server=on,wait=off,abstract=on

2. Check the chardev info, the socket address changed:
(qemu)info chardev
serial0: filename=vc
compat_monitor0: filename=stdio
channel0: filename=disconnected:unix:/tmp/port0U,abstract,tight,server=on


3. Connect the socket using the changed address, will fail.
# socat abstract-connect:/tmp/port0U - 
2021/07/19 09:38:18 socat[236167] E connect(5, AF=1 "\0/tmp/port0U", 14): Connection refused


4. Connect the socket using the original socket address, will success.
# socat abstract-connect:/tmp/port0 -



Actual results:
socket address gets a wrong name in qemu



Expected results:
socket address shows right.


Additional info:

Comment 1 John Ferlan 2021-07-20 15:54:12 UTC

Once we have the downstream bz accepted we can use the downstream commit id in the devel whiteboard and move this along to POST using bug 1957194 as a depends on

Comment 2 John Ferlan 2021-08-09 14:42:47 UTC

Moving this to 9.0.0, POST, but not picking DTM at this point as there isn't a weekly rebase schedule for rhel9 yet.  Once/if qemu-6.1 gets merged into a rhel9 branch, I'll update.

Comment 3 Yanan Fu 2021-10-12 06:48:23 UTC

Set 'Verified:Tested,SanityOnly' as gating test with qemu-kvm-6.1.0-1.el9 pass

Comment 4 liunana 2021-10-14 07:21:12 UTC

Test PASS


Test Env:
    5.14.0-4.el9.x86_64
    qemu-kvm-6.1.0-1.el9.x86_64


Test Steps:

1. boot qemu with command:
# /usr/libexec/qemu-kvm -monitor stdio -chardev socket,id=channel0,path=/tmp/port0,server=on,wait=off,abstract=on -qmp tcp:0:4444,server,nowait

2. check the socket path address, it is true.
(qemu)info chardev
channel0: filename=disconnected:unix:/tmp/port0,abstract=on,tight=on,server=on

 {"execute":"query-chardev"}
{"return": [{"frontend-open": true, "filename": "tcp:10.73.178.85:4444,server=on <-> 10.73.178.85:60440", "label": "compat_monitor1"}, {"frontend-open": false, "filename": "disconnected:unix:/tmp/port0,abstract=on,tight=on,server=on", "label": "channel0"}, {"frontend-open": true, "filename": "stdio", "label": "compat_monitor0"}, {"frontend-open": true, "filename": "vc", "label": "serial0"}]}



I will move this bug to verified directly once it is ON_QA. Thanks.



Best regards
Liu Nana

Comment 8 liunana 2021-12-20 03:25:03 UTC

Move this to verified according to Comment 4.

Comment 10 errata-xmlrpc 2022-05-17 12:23:27 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 (new packages: qemu-kvm), 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-2022:2307