Hi, 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. Hopefully someone on this list is more familiar with how this all works and can point out what I'm missing! Regards, Matt Broadstone