Bug 1166031

Summary: Windows and Linux guest can not receive data from host via virtserialport via Unix socket backend
Product: Red Hat Enterprise Linux 7 Reporter: lijin <lijin>
Component: qemu-kvm-rhevAssignee: Amit Shah <amit.shah>
Status: CLOSED ERRATA QA Contact: Min Deng <mdeng>
Severity: urgent Docs Contact:
Priority: urgent    
Version: 7.1CC: amit.shah, chayang, ghammer, hhuang, huding, juzhang, knoel, lijin, mdeng, michen, mrezanin, phou, rbalakri, virt-bugs, virt-maint, vrozenfe, wyu, yduan
Target Milestone: rcKeywords: Regression, TestBlocker
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: qemu-2.5 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1601695 (view as bug list) Environment:
Last Closed: 2016-11-07 20:16:46 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:
Bug Depends On:    
Bug Blocks: 1288337, 1601695, 1714393    

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