Does this happen on the opposite direction too? Does the first message send from the host to the guest is lost too?

Hi, Jakub
could you please help answer the above question? thanks.

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

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.

(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

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

It is definitely connected - through this dev agent communicates with vdsm.

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.

I checked that very first message sent from agent is delivered to vdsm correctly.

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

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.

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.

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.

(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?

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

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

(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

One of the several bugs that need a rewrite of the qemu chardev layer.  Moving to RHEL7.

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.

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