Bug 729923 - [virtio-serial] First message is not delivered after connected to virtio-port
Summary: [virtio-serial] First message is not delivered after connected to virtio-port
Keywords:
Status: CLOSED DUPLICATE of bug 702271
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm
Version: 7.0
Hardware: x86_64
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Amit Shah
QA Contact: Virtualization Bugs
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-11 09:56 UTC by Jakub Libosvar
Modified: 2014-07-21 12:53 UTC (History)
13 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-07-21 12:53:52 UTC
ghammer: needinfo-


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 909059 None None None Never

Internal Links: 909059

Description Jakub Libosvar 2011-08-11 09:56:53 UTC
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 06:06:16 UTC
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 09:25:43 UTC
Hi, Jakub
could you please help answer the above question? thanks.

Comment 4 Jakub Libosvar 2011-08-15 16:28:03 UTC
(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 13:54:42 UTC
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 07:11:19 UTC
(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 08:51:05 UTC
(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 08:59:18 UTC
It is definitely connected - through this dev agent communicates with vdsm.

Comment 9 Amit Shah 2011-09-05 09:36:42 UTC
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 10:24:57 UTC
I checked that very first message sent from agent is delivered to vdsm correctly.

Comment 11 Amit Shah 2011-09-05 10:51:09 UTC
(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 08:52:17 UTC
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 18:12:07 UTC
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-11 02:00:26 UTC
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 05:57:14 UTC
(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 06:01:23 UTC
(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 06:49:42 UTC
(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 11:54:27 UTC
(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 11:44:37 UTC
One of the several bugs that need a rewrite of the qemu chardev layer.  Moving to RHEL7.

Comment 25 Jiri Belka 2013-06-10 11:48:21 UTC
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 12:53:52 UTC

*** 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.