Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
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 729923

Summary: [virtio-serial] First message is not delivered after connected to virtio-port
Product: Red Hat Enterprise Linux 7 Reporter: Jakub Libosvar <jlibosva>
Component: qemu-kvmAssignee: Amit Shah <amit.shah>
Status: CLOSED DUPLICATE QA Contact: Virtualization Bugs <virt-bugs>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.0CC: bazulay, ghammer, iheim, jbelka, juzhang, michen, mkenneth, mshao, qzhang, rhod, soeren.grunewald, tburke, virt-maint
Target Milestone: rcFlags: ghammer: needinfo-
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2014-07-21 12:53:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

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