libvirt users - Sep 2013 - Re: Trouble using virStream with callbacks

On Thu, Sep 19, 2013 at 11:59:45AM -0400, Jonathan Lebon
wrote:
> I tried to dig a bit deeper in this. From my limited understanding,
> it seems like stream events are implemented as enabled/disabled timers.
> The issue is that if there's no data from the guest app pending, the
> timeout in virEventPollRunOnce will be calculated as -1. So then we
> block on the poll() and only come out once stdin is ready for reading.
> 
> This means that if data is received from the guest during the blocking
> poll(), there will be no dispatching until something happens on stdin
> and poll() returns (hence why you have to <Enter> twice).
poll() will be listening for i/o on the libvirt socket as well as
stdin, so it'll see incoming I/O from the guest.
> I'm sure there's a better solution, but is there any way to force
the
> timer created for streams to always be 0? Or even to use ppoll()
> instead of poll() and arrange for a benign signal upon stream events?
> Hopefully my analysis wasn't too far off.
I don't think that is the case. The streams/events code is already used
for the 'virsh console' command implementation which doesn't suffer
from
the problem you describe.

One relevant thing is that stdio is line buffered by default and you
aren't putting it into raw mode like virsh console does. This will
delay I/O on the stdio streams.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|

> poll() will be listening for i/o on the libvirt socket as well as
> stdin, so it'll see incoming I/O from the guest.
That's strange, that's not what I'm seeing when running it
step-by-step. I see
poll() hanging regardless of guest events. There are indeed two fds in the
array (stdin and the other one being the libvirt socket I suppose), but in all
cases, I never observed an event occurring on the libvirt socket. Am I missing
a call to something here?

Note that I'm using 1.0.5.5 (daemon and library). Could things have changed
recently?
> One relevant thing is that stdio is line buffered by default and you
> aren't putting it into raw mode like virsh console does. This will
> delay I/O on the stdio streams.
That's a good point. But since all the messages between host and guest end
in newlines, that shouldn't be an issue, right? Anyway, I can see the lines
from stdin making it to virStreamSend() upon the first <Enter>. And from
the
other side, it's safe to assume socat sends the data after the first
<Enter>
as well (since it works fine with socat to socat directly on the socket/port).


Thanks,

Jonathan

On Thu, Sep 19, 2013 at 12:59:33PM -0400, Jonathan Lebon
wrote:
> > poll() will be listening for i/o on the libvirt socket as well as
> > stdin, so it'll see incoming I/O from the guest.
> 
> That's strange, that's not what I'm seeing when running it
step-by-step. I see
> poll() hanging regardless of guest events. There are indeed two fds in the
> array (stdin and the other one being the libvirt socket I suppose), but in
all
> cases, I never observed an event occurring on the libvirt socket. Am I
missing
> a call to something here?
> 
> Note that I'm using 1.0.5.5 (daemon and library). Could things have
changed
> recently?
We've had quite a few changes sinc that release, so its always possible,
but at the smae time 'virsh console' has been using this code along time
and no one has complained about the problem you describe.
> 
> > One relevant thing is that stdio is line buffered by default and you
> > aren't putting it into raw mode like virsh console does. This will
> > delay I/O on the stdio streams.
> 
> That's a good point. But since all the messages between host and guest
end
> in newlines, that shouldn't be an issue, right? Anyway, I can see the
lines
> from stdin making it to virStreamSend() upon the first <Enter>. And
from the
> other side, it's safe to assume socat sends the data after the first
<Enter>
> as well (since it works fine with socat to socat directly on the
socket/port).
As a test why not try hacking virsh console so that it connects to your
virtio serial port, instead of a console. If we assume 'virsh console'
is bug-free, that would let you identify whether the flaw is in your host
code, or the guest side.

Daniel
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|