RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1166031 - Windows and Linux guest can not receive data from host via virtserialport via Unix socket backend
Summary: Windows and Linux guest can not receive data from host via virtserialport via...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Min Deng
URL:
Whiteboard:
Depends On:
Blocks: 1288337 1601695 1714393
TreeView+ depends on / blocked
 
Reported: 2014-11-20 10:10 UTC by lijin
Modified: 2019-05-28 02:42 UTC (History)
18 users (show)

Fixed In Version: qemu-2.5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1601695 (view as bug list)
Environment:
Last Closed: 2016-11-07 20:16:46 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 0 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description lijin 2014-11-20 10:10:43 UTC
Description of problem:
boot guest with virtioserialport,guest can send data to host,but cannot receive data from host.
cannot reproduce this issue with qemu-kvm-1.5.3-79.el7.x86_64

Version-Release number of selected component (if applicable):
qemu-kvm-rhev-2.1.2-9.el7.x86_64
kernel-3.10.0-200.el7.x86_64
seabios-1.7.5-5.el7.x86_64
virtio-win-prewhql-94

How reproducible:
100%

Steps to Reproduce:
1.boot win7-32 guest with one virtio-serial-pci and two virtserialport2:
/usr/libexec/qemu-kvm -drive file=win7-32.qcow2,if=none,cache=none,media=disk,format=qcow2,id=disk1 -device ide-drive,id=ide0-0-0,drive=disk1,bootindex=0 -monitor stdio -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:06:7f:f9:56,bus=pci.0,addr=0x4 -boot menu=on -vnc :0 -vga cirrus -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -usb -device usb-tablet,id=tablet1 -smp 2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 \
-device virtio-serial-pci,id=virtio-serial0,max_ports=31,bus=pci.0 \
-chardev socket,path=/tmp/tt0,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0 \
-chardev socket,path=/tmp/tt1,server,nowait,id=chardev1 -device virtserialport,chardev=chardev1,name=com.redhat.rhevm.vdsm1,bus=virtio-serial0.0,id=port1 \

2.Transferring data form host to guest via port0
Guest:python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm
Host:python serial-host-send.py /tmp/tt0 

Actual results:
after step2,host send the data,guest keep still at the receiving status,no data were received.

Expected results:
guest can receive data from host

Additional info:
1.windows guest can send data to host and host can receive the data correctly;
2.retest with qemu-kvm-1.5.3-79.el7.x86_64,guest didnot hit this issue,guest can send/receive data successfully;
3.rhel7.1 guest didnot hit this issue;
4.rhel6.6 guest didnot hit this issue;
5.windows guest cannot reproduce this issue on rhel6.6 host;

Comment 2 Mike Cao 2014-11-20 10:34:57 UTC
According to dgilbert's advice ,move bug to virtio-win component first 

Mike

Comment 4 Gal Hammer 2014-11-20 15:58:05 UTC
I was able to reproduce with the serial test python scripts.

However it seems that it works okay if using "nc -U /tmp/vport0" (or "socat unix-connect:/tmp/vport0 -") to connect from the host side and send data to the guest.

Comment 5 lijin 2014-11-21 02:49:36 UTC
(In reply to Gal Hammer from comment #4)
> I was able to reproduce with the serial test python scripts.
> 
> However it seems that it works okay if using "nc -U /tmp/vport0" (or "socat
> unix-connect:/tmp/vport0 -") to connect from the host side and send data to
> the guest.

yes,QE retest via "nc -U /tmp/tt0",guest can receive data successfully. 

steps:
host:
#echo helloguest | nc -U /tmp/tt0

guest:
CLI: #vioser-test.exe
     #r

Comment 6 Gal Hammer 2014-11-23 14:11:31 UTC
After further look, it looks like the problem is with the way the scripts works (open a port, write to the port and then close it). It cause either qemu or the guest to drop the messages because it assume that there is no listener on the other side.

Amit? Did something change between qemu 1.5.3 and 2.1.2 which is related to the detection of a connect/disconnect to a char device?

Comment 7 Amit Shah 2014-11-24 09:46:59 UTC
(In reply to Gal Hammer from comment #6)
> Amit? Did something change between qemu 1.5.3 and 2.1.2 which is related to
> the detection of a connect/disconnect to a char device?

No, nothing comes to mind.  RHEL guests work fine according to comment 0, so at least that hints it may not be a qemu issue.

Comment 8 Mike Cao 2014-11-24 10:13:26 UTC
(In reply to Gal Hammer from comment #6)
> After further look, it looks like the problem is with the way the scripts
> works (open a port, write to the port and then close it). It cause either
> qemu or the guest to drop the messages because it assume that there is no
> listener on the other side.
> 
May I know the difference between vioser-test.exe and QE's python scripts for transferring data ?

Thanks,
Mike

Comment 9 Gal Hammer 2014-11-24 10:33:31 UTC
(In reply to Mike Cao from comment #8)
> (In reply to Gal Hammer from comment #6)
> > After further look, it looks like the problem is with the way the scripts
> > works (open a port, write to the port and then close it). It cause either
> > qemu or the guest to drop the messages because it assume that there is no
> > listener on the other side.
> > 
> May I know the difference between vioser-test.exe and QE's python scripts
> for transferring data ?
> 
> Thanks,
> Mike

I'm not familiar with vioser-test.exe code. I assume that the difference is because the Python's scripts open and close the port after each read/write.

Comment 10 Mike Cao 2014-11-24 10:37:38 UTC
Vadim ,Can you help to answer comment #8 as you are the author of vioser-test.exe

Thanks in advance,
Mike

Comment 11 Vadim Rozenfeld 2014-11-24 13:04:05 UTC
vioser-test doesn't close the open handler between the tests. But it's probably not the only difference. The application was designed to test both - blocking and non-blocking IO. By default it is running in non-blocking mode, but it will operate in blocked mode if was started with "-n" flag.

Vadim.

Comment 12 Mike Cao 2014-11-24 14:29:00 UTC
(In reply to Vadim Rozenfeld from comment #11)
> vioser-test doesn't close the open handler between the tests. But it's
> probably not the only difference. The application was designed to test both
> - blocking and non-blocking IO. By default it is running in non-blocking
> mode, but it will operate in blocked mode if was started with "-n" flag.
> 
> Vadim.

Blocking mode is not supported now if I remember clearly.
Mike

Comment 13 lijin 2014-11-25 07:07:57 UTC
guest also hit this issue with virtio-win-1.7.2-2.el6.noarch,so this is not a virtio-win regression bug

Comment 15 lijin 2014-11-26 07:06:51 UTC
guest does NOT hit this issue when change the socket backend to "-chardev socket,host=localhost,port=12345,server,nowait,id=chardev0"

steps:
1.boot guest with 
/usr/libexec/qemu-kvm -drive file=win7-32.qcow2,if=none,cache=none,media=disk,format=qcow2,id=disk1 -device ide-drive,id=ide0-0-0,drive=disk1,bootindex=0 -monitor stdio -netdev tap,id=hostnet0 -device e1000,netdev=hostnet0,id=net0,mac=52:54:06:7f:f9:56,bus=pci.0,addr=0x4 -boot menu=on -vnc :0 -vga cirrus -chardev file,path=/root/console.log,id=serial1 -device isa-serial,chardev=serial1,id=s1 -usb -device usb-tablet,id=tablet1 -smp 2,cores=2,threads=1,sockets=1 -m 2G -enable-kvm -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0 -device virtio-serial-pci,id=virtio-serial0,max_ports=31,bus=pci.0 -chardev socket,host=localhost,port=12345,server,nowait,id=chardev0 -device virtserialport,chardev=chardev0,name=com.redhat.rhevm.vdsm,bus=virtio-serial0.0,id=port0

2.Transferring data form host to guest via port0
Guest: 
python VirtIOChannel_guest_reieve.py com.redhat.rhevm.vdsm
Host: 
2.1 modify serial-host-send.py script
#vport = socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) ---> commented out
#vport.connect(sys.argv[1])                                ---> commented out
vport = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
vport.connect((HOST, PORT))
2.2 python serial-host-send.py

Actual result:
guest can receive data correctly.

Comment 16 Mike Cao 2014-11-26 07:13:55 UTC
Based on above ,this is qemu-kvm-rhev regression bug

Comment 17 lijin 2014-11-26 09:37:33 UTC
rhel guest didnot hit this issue in comment #0 is due to QE use "nc -U" to transfer data instead of using the python scripts.
QE retest with python script,rhel7.1 guest also hit this issue:guest cannot receive data with unix socket and works fine with tcp socket.

Comment 18 Ronen Hod 2014-11-26 16:08:41 UTC
Regardless of the regression ...
The issue is that the Windows guest is doing a blocking read, but the definition of read is not clear, and the current behavior is:
- If there is a connection from the host, then the guest will block, waiting for data to arrive.
- If there is no connection, the guest does not block (wait for a connection), and exits right away.
The test script on the host repeatedly "connects, sends data, and disconnects", so if the guest reads the data when the host is disconnected then the data is lost.
Deferring to 7.2, Regardless of the proper solution.

Comment 19 Ronen Hod 2014-11-27 11:50:45 UTC
Comment 17 indicates that the issue is in QEMU. Reassigning to Amit.
As I wrote in comment 18, I am not sure that there is a bug.

Comment 23 Amit Shah 2015-09-01 03:24:32 UTC
This is another bug that doesn't work for connect, send, disconnect, repeat sequences.  We need a better io loop in qemu (esp. we need to detect POLLHUP, and terminate a connection).  The host doesn't realise the chardev is disconnected, so it just misses new data from the connection.  From comment 15, tcp works fine; so this is specific to unix chardevs.  That's strange.

Comment 27 Peixiu Hou 2016-03-31 09:41:24 UTC
Reproduced this issue on qemu-kvm-rhev-2.1.2-23.el7_1.1.x86_64.

Verified this issue on qemu-kvm-rhev-2.5.0-1.el7.x86_64, didnot hit this issue. the issue has been fixed.

Best Regards~
Peixiu Hou

Comment 28 Amit Shah 2016-07-13 05:38:32 UTC
(In reply to Peixiu Hou from comment #27)
> Reproduced this issue on qemu-kvm-rhev-2.1.2-23.el7_1.1.x86_64.
> 
> Verified this issue on qemu-kvm-rhev-2.5.0-1.el7.x86_64, didnot hit this
> issue. the issue has been fixed.

Thanks!

Closing.

Comment 30 lijin 2016-09-06 01:17:38 UTC
Verify this bug on qemu-kvm-rhev-2.6.0-21.el7.x86_64

Steps are same as comment#0,guest/host can transfer data via unix socket backend.

So this issue has been fixed already,change status to verified.

Comment 31 yduan 2016-09-08 05:51:33 UTC
RHEL guest: reproduced with qemu-kvm-rhev-2.1.2-23.el7.x86_64 and verified with qemu-kvm-rhev-2.6.0-23.el7.x86_64.

Version-Release number of selected component (if applicable):
kernel: 3.10.0-500.el7.x86_64 (both host and guest)
seabios-1.9.1-4.el7.x86_64

Steps are same as comment 0.

Comment 33 errata-xmlrpc 2016-11-07 20:16:46 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.

https://rhn.redhat.com/errata/RHBA-2016-2673.html


Note You need to log in before you can comment on or make changes to this bug.