Bug 1080376

Michal, is what you want basically that an EOF be reported on the host-side end of the virtio-serial port (ie. read() == 0) when the last guest-side process that keeps it open exits? Because if so, that sounds to me like a kernel BZ.

... and/or a qemu chardev change. That sounds quite horrible to me; I'm not a chardev expert. Maybe Amit or Gerd could help?...

We have open/close inside qemu for chardevs, so qemu knows whenever someone is listening inside the guest.  So I think it boils down to how communicate that to libvirt.

We could add the info to query-chardev and send qmp events on open/close, I suspect that is the only way to make it work in general.

For some chardev types we can try use the data channel directly, for example by using out-of-band messages on unix/tcp sockets.

(In reply to Laszlo Ersek from comment #2)
> Michal, is what you want basically that an EOF be reported on the host-side
> end of the virtio-serial port (ie. read() == 0) when the last guest-side
> process that keeps it open exits? Because if so, that sounds to me like a
> kernel BZ.

Yes, that's what I'm trying to achieve. Libvirt allows some API execution depending on qemu-ga being set up and listening within the guest (virDomainFSTrim being an example). However, as described in the description, it may happen that the API will hang up indefinitely - i.e. if the guest agent sigsegvs meanwhile. So it would be really great if libvirt could see EOF on the host side of the virtio-serial port. Because then libvirt can undertake some actions.

I'm not sure what would be easier / cleaner to do in qemu, while keeping the chardev infrastructure general:
- keep the host side (unix) fd and the guest-side (virtio-serial) fd in tight correspondence (EOF seen on the host-side end of virtio-serial would cause qemu to close its server side of the unix domain socket, making libvirt read EOF)
- emit an event at guest-initiated closure (Gerd's comment 5)

This thing should be redetectable for libvirt. For example, if libvirt is restarted, the new instance won't get a new event from qemu. The new instance of libvirt should somehow immediately see that the agent is not connected, eg. by getting ECONNREFUSED when connecting to the unix domain socket.

I'm not sure if qemu can close() and then re-run socket()+bind()+listen()+accept() on the unix domain socket *in sync* with what it sees on the host-side of the virtio-serial port.

virtio-console gets notification when the guest-side port is opened or closed:

/* Callback function that's called when the guest opens/closes the port */
static void set_guest_connected(VirtIOSerialPort *port, int guest_connected)


An event can be exposed for libvirt so libvirt knows too.  Also, 'info qtree' mentions 'guest off' if the guest is not connected; a restarted libvirt could check that (albeit it's a hacky way; there's no standard way of reporting that).

Upstream v1 posted:
http://thread.gmane.org/gmane.comp.emulators.qemu/276342

Posted upstream v2:
http://thread.gmane.org/gmane.comp.emulators.qemu/283238

Posted upstream v3:
http://lists.nongnu.org/archive/html/qemu-devel/2014-06/msg06560.html

Now upstream:

1  e2ae615 virtio-serial: report frontend connection state via monitor
2  32a97ea char: report frontend open/closed state in 'query-chardev'

Laszlo did some analysis and the backport of this feature is too risky for RHEL6. Customers who need this feature are advised to move to RHEL7.