Bug 729923 - [virtio-serial] First message is not delivered after connected to virtio-port
[virtio-serial] First message is not delivered after connected to virtio-port
Status: CLOSED DUPLICATE of bug 702271
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm (Show other bugs)
7.0
x86_64 Linux
medium Severity medium
: rc
: ---
Assigned To: Amit Shah
Virtualization Bugs
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2011-08-11 05:56 EDT by Jakub Libosvar
Modified: 2014-07-21 08:53 EDT (History)
13 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-07-21 08:53:52 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ghammer: needinfo-


Attachments (Terms of Use)

  None (edit)
Description Jakub Libosvar 2011-08-11 05:56:53 EDT
Description of problem:
When somebody is connected to the virtio-serial socket, the first message sent from the other side is not delivered to this socket.

Version-Release number of selected component (if applicable):
qemu-kvm-0.12.1.2-2.172.el6.x86_64

How reproducible:
Always

Steps to Reproduce:
1. Install rhel6-x64 guest on some rhel6 host with vdsm

On guest
========
2. Run the guest and install rhev-agent therefore virtio-serial port is created inside the guest (rpm -Uvh http://download.devel.redhat.com/brewroot/packages/rhev-agent/2.3.12/1.el6/x86_64/rhev-agent-2.3.12-1.el6.x86_64.rpm)
3. start guest on agent (service rhev-agentd start)
4. stop agent

On host
=======
5. stop vdsm (service vdsmd stop)
6. connect to virtio-socket (nc -U /var/lib/libvirt/qemu/monitor/<vmname>.monitor)

On guest
========
7. send message to virtio-port (echo "1" >> /dev/virtio-ports/com.redhat.rhevm.vdsm)
8. send another message (echo "2" >> /dev/virtio-ports/com.redhat.rhevm.vdsm)
  
Actual results:
message '1' is not delivered to the host side of virtio

Expected results:
Both messages are delivered.

Additional info:
Are there any logs that would be helpful?

qemu process: /usr/libexec/qemu-kvm -S -M rhel6.0.0 -cpu Conroe -enable-kvm -m 1024 -smp 2,sockets=2,cores=1,threads=1 -name rhel57-x64 -uuid bf612281-f771-437a-a515-9fae563adf5d -smbios type=1,manufacturer=Red Hat,product=RHEL,version=6Server-6.1.0.2.el6_1,serial=44454C4C-4200-1031-804D-C7C04F31354A_78:2B:CB:8D:8F:9D,uuid=bf612281-f771-437a-a515-9fae563adf5d -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/rhel57-x64.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2011-08-11T08:20:08 -no-shutdown -device virtio-serial-pci,id=virtio-serial0,max_ports=16,bus=pci.0,addr=0x4 -drive file=/rhev/data-center/15e9ee19-f367-4717-8665-38fd80ae57a3/678fd024-039e-459f-9c9e-3c0b5ab32f6a/images/93b911d1-a668-4d89-af4e-0acaf72ddfcc/a6b39b3f-a939-466d-b38d-6c035b68c795,if=none,id=drive-virtio-disk0,format=raw,serial=89-af4e-0acaf72ddfcc,cache=none,werror=stop,rerror=stop,aio=native -device virtio-blk-pci,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0,bootindex=2 -netdev tap,fd=27,id=hostnet0,vhost=on,vhostfd=28 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:30:39:18,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/rhel57-x64.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -usb -device usb-tablet,id=input0 -vnc 0:0,password -k en-us -vga cirrus
Comment 2 Gal Hammer 2011-08-14 02:06:16 EDT
Does this happen on the opposite direction too? Does the first message send from the host to the guest is lost too?
Comment 3 Miya Chen 2011-08-15 05:25:43 EDT
Hi, Jakub
could you please help answer the above question? thanks.
Comment 4 Jakub Libosvar 2011-08-15 12:28:03 EDT
(In reply to comment #2)
> Does this happen on the opposite direction too? Does the first message send
> from the host to the guest is lost too?

No, it's not.
Comment 5 Amit Shah 2011-09-02 09:54:42 EDT
Does vdsm connect to the chardev that virtio-serial uses?  It then could be the bug where qemu doesn't realise a disconnect event has happened.

btw, in the original comment, you mention you connect to /var/lib/libvirt/qemu/monitor/<vmname>.monitor.  That's the monitor socket; I'm assuming you actually connect to the socket that's opened for the virtio-serial port.
Comment 6 Jakub Libosvar 2011-09-05 03:11:19 EDT
(In reply to comment #5)
> Does vdsm connect to the chardev that virtio-serial uses?  It then could be the
> bug where qemu doesn't realise a disconnect event has happened.

You mean that vdsm was connected, then stopped and here qemu doesn't know about disconnect so it ignores next message?

> btw, in the original comment, you mention you connect to
> /var/lib/libvirt/qemu/monitor/<vmname>.monitor.  That's the monitor socket; I'm
> assuming you actually connect to the socket that's opened for the virtio-serial
> port.

Sorry, I was writing it, not copied - correct path is /var/lib/libvirt/qemu/channels/<vmname>.com.redhat.rhevm.vdsm
Comment 7 Amit Shah 2011-09-05 04:51:05 EDT
(In reply to comment #6)
> (In reply to comment #5)
> > Does vdsm connect to the chardev that virtio-serial uses?  It then could be the
> > bug where qemu doesn't realise a disconnect event has happened.
> 
> You mean that vdsm was connected, then stopped and here qemu doesn't know about
> disconnect so it ignores next message?

Right.
Comment 8 Jakub Libosvar 2011-09-05 04:59:18 EDT
It is definitely connected - through this dev agent communicates with vdsm.
Comment 9 Amit Shah 2011-09-05 05:36:42 EDT
OK, so there are a few similar bugs, but they all point in the same direction - qemu doesn't recognise host chardev disconnect, so one message from guest->host may get lost.

Bug 728878 and bug 702271 are the related ones.
Comment 10 Jakub Libosvar 2011-09-05 06:24:57 EDT
I checked that very first message sent from agent is delivered to vdsm correctly.
Comment 11 Amit Shah 2011-09-05 06:51:09 EDT
(In reply to comment #10)
> I checked that very first message sent from agent is delivered to vdsm
> correctly.

Exactly; then you disconnect vdsm, qemu doesn't register that disconnect.  The next message from the guest then gets quietly eaten up.  This is when qemu realises that it needs to close the stale connection.  The next message is then successfully delivered on the new connection.
Comment 12 RHEL Product and Program Management 2012-07-10 04:52:17 EDT
This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.
Comment 13 Soeren Grunewald 2012-07-10 14:12:07 EDT
I just run in a similar issue, running ovirt (using http://www.dreyou.org ) on 6.3 and tried to install a fedora 17 (Bug 837925).

Rebuild the qemu-kvm package 0.12.1.2-2.295 with this patch [http://git.qemu.org/?p=qemu.git;a=commit;h=ed8e5a85a1741147ce06932b478a509ce3407061] solves the issue.
Comment 14 RHEL Product and Program Management 2012-07-10 22:00:26 EDT
This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.
Comment 15 Amit Shah 2012-07-11 01:57:14 EDT
(In reply to comment #13)
> I just run in a similar issue, running ovirt (using http://www.dreyou.org )
> on 6.3 and tried to install a fedora 17 (Bug 837925).
> 
> Rebuild the qemu-kvm package 0.12.1.2-2.295 with this patch
> [http://git.qemu.org/?p=qemu.git;a=commit;
> h=ed8e5a85a1741147ce06932b478a509ce3407061] solves the issue.

That is odd.  That commit only affects console ports.  What's your qemu-kvm command line?
Comment 16 Amit Shah 2012-07-11 02:01:23 EDT
(In reply to comment #13)
> I just run in a similar issue, running ovirt (using http://www.dreyou.org )
> on 6.3 and tried to install a fedora 17 (Bug 837925).

Bug 837925 indeed does use console ports, and your bug is similar to that one.  This bug talks about non-console port behaviour, and is quite different from what you saw.
Comment 17 Amit Shah 2012-07-11 02:49:42 EDT
(In reply to comment #13)
> I just run in a similar issue, running ovirt (using http://www.dreyou.org )
> on 6.3 and tried to install a fedora 17 (Bug 837925).
> 
> Rebuild the qemu-kvm package 0.12.1.2-2.295 with this patch
> [http://git.qemu.org/?p=qemu.git;a=commit;
> h=ed8e5a85a1741147ce06932b478a509ce3407061] solves the issue.

Thanks, the fix for that bug is now tracked in bug 839156.
Comment 18 Soeren Grunewald 2012-07-11 07:54:27 EDT
(In reply to comment #15)
> (In reply to comment #13)
> > I just run in a similar issue, running ovirt (using http://www.dreyou.org )
> > on 6.3 and tried to install a fedora 17 (Bug 837925).
> > 
> > Rebuild the qemu-kvm package 0.12.1.2-2.295 with this patch
> > [http://git.qemu.org/?p=qemu.git;a=commit;
> > h=ed8e5a85a1741147ce06932b478a509ce3407061] solves the issue.
> 
> That is odd.  That commit only affects console ports.  What's your qemu-kvm
> command line?

This is the command line:

LC_ALL=C PATH=/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/sbin:/sbin:/bin QEMU_AUDIO_DRV=spice /usr/libexec/qemu-kvm -S -M rhel6.3.0 -cpu Opteron_G3 -enable-kvm -m 1024 -smp 4,sockets=2,cores=2,threads=1 -name f17-build -uuid 98b6d6d0-5ca0-405f-be54-58d32a237767 -smbios type=1,manufacturer=Red Hat,product=RHEV Hypervisor,version=6-3.el6.centos.9,serial=49434D53-0200-9049-2500-499025000B68_00:25:90:49:68:0a,uuid=98b6d6d0-5ca0-405f-be54-58d32a237767 -nodefconfig -nodefaults -chardev socket,id=charmonitor,path=/var/lib/libvirt/qemu/f17-build.monitor,server,nowait -mon chardev=charmonitor,id=monitor,mode=control -rtc base=2012-07-10T17:53:35,driftfix=slew -no-shutdown -device piix3-usb-uhci,id=usb,bus=pci.0,addr=0x1.0x2 -device virtio-serial-pci,id=virtio-serial0,bus=pci.0,addr=0x4 -drive if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw,serial= -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0 -drive file=/rhev/data-center/b1e0ae94-b979-11e1-0c7-525400a353ed/2ab09c1c-6092-4c90-94b8-97802e804182/images/c73138fa-5d5b-42a6-a9c7-49914534d31a/03bc0a86-8d47-43d6-a740-ec00c0577e98,if=none,id=drive-virtio-disk0,format=raw,serial=c73138fa-5d5b-42a6-a9c7-49914534d31a,cache=none,werror=stop,rerror=stop,aio=threads -device virtio-blk-pci,scsi=off,bus=pci.0,addr=0x5,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=1 -netdev tap,fd=22,id=hostnet0,vhost=on,vhostfd=23 -device virtio-net-pci,netdev=hostnet0,id=net0,mac=00:1a:4a:14:1e:06,bus=pci.0,addr=0x3 -chardev socket,id=charchannel0,path=/var/lib/libvirt/qemu/channels/f17-build.com.redhat.rhevm.vdsm,server,nowait -device virtserialport,bus=virtio-serial0.0,nr=1,chardev=charchannel0,id=channel0,name=com.redhat.rhevm.vdsm -chardev spicevmc,id=charchannel1,name=vdagent -device virtserialport,bus=virtio-serial0.0,nr=2,chardev=charchannel1,id=channel1,name=com.redhat.spice.0 -chardev pty,id=charconsole0 -device virtconsole,chardev=charconsole0,id=console0 -spice port=5903,addr=0 -k en-us -vga qxl -global qxl-vga.vram_size=67108864 -device virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x6
Comment 19 Amit Shah 2012-07-23 07:44:37 EDT
One of the several bugs that need a rewrite of the qemu chardev layer.  Moving to RHEL7.
Comment 25 Jiri Belka 2013-06-10 07:48:21 EDT
I tried with qemu-kvm-rhev-0.12.1.2-2.374.el6.x86_64, as this is the qemu package name for new rhevm. Though not sure if this has same diffs included as qemu-kvm-0.12.1.2-2.374.el6.x86_64. Anyway, I didn't see any message at all.
Comment 27 Amit Shah 2014-07-21 08:53:52 EDT

*** This bug has been marked as a duplicate of bug 702271 ***

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