qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Matt Broadstone
Subject: [Qemu-devel] qemu-ga virtio-serial socket clarification
Date: Tue, 25 Oct 2016 14:14:24 -0400

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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]