Re: [Qemu-devel] qemu-ga virtio-serial socket clarification

[Matt Broadstone]

On Tue, Oct 25, 2016 at 6:27 PM, Stefan Hajnoczi <address@hidden> wrote:

> On Tue, Oct 25, 2016 at 7:14 PM, Matt Broadstone <address@hidden>
> wrote:
> > I've been attempting an experimental qemu agent using a node.js daemon on
> > the host side, and have run into an issue I was hoping someone here might
> > be able to help with:
> >
> > Using libvirt I've set up a 'unix' channel for a domain using
> virtio-serial
> > (the same way you would for the existing qemu agent) with the name
> > 'test.agent', in order to bypass libvirt taking ownership of the domain
> > socket. This works as expected, and so does the following test:
> >
> >  - [host] $ echo "testing" | nc -U
> > /var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent
> >  - [guest] $ cat -v < /dev/virtio-ports/test.agent
> >
> > Then I tried the same test, converting the host->guest communication to
> > node.js:
> >
> > 'use strict';
> > const net = require('net');
> > const socketPath =
> > '/var/lib/libvirt/qemu/channel/target/domain-T40001/test.agent';
> > let socket = net.createConnection(socketPath);
> > socket.write('testing');
> >
> > In this case the data makes it across to the guest, however until I
> > explicitly close the socket on the sender side (`socket.write('testing',
> ()
> > => socket.end())`) both sides block indefinitely. I understand closing
> the
> > socket brings the node example to parity with the netcat one, however
> after
> > perusing the qemu-ga and libvirt repositories it looks like glib's io
> > channels are being used on a single socket, and effectively handling
> > bidirectional data.
> >
> > Is this the expected behavior?
> >
> > This would seem to imply that normal async communication over the domain
> > socket is somehow different in the virtio-serial case (as in I can't
> > maintain a duplex socket, but would rather have to juggle opening and
> > closing read/write sockets). In my research I came across another similar
> > project: https://github.com/xolox/python-negotiator, which requires two
> > channels: one for host->guest communication, and another for guest->host
> > communication, likely because of this very issue.
>
> virtio-serial is full-duplex.
>
> Please post the receive side test program you are using.
>
> Stefan
>

Stefan,

The receive side in this case is the same as above: `cat -v <
/dev/virtio-ports/test.agent`, the only variable here is the sending side
changing to the posted node script.

Matt