On 11/04/16 23:18, Stefan Hajnoczi wrote: > On Fri, Nov 4, 2016 at 9:46 PM, Matt Broadstone <mbroa...@gmail.com> wrote: >> I've progressed with creating my own agent, and have successfully been >> able to communicate over virtio-serial channels in order to provide >> two-way communication between hypervisor and guest. My problem now >> seems to be related to _when_ to start listening to the domain sockets >> - specifically it seems that if I start listening to the domain >> sockets on the hypervisor side before the guest (in this case windows >> guest) is fully loaded, communication will fail over the channel until >> both sides hangup and try again. Is there any documentation on this >> behavior, or guidelines I should be following for when to begin >> communication over the channels? > > That sounds odd. I'd expect communicate to work as soon as both host > and guest are ready. > > Have you tried a Linux guest instead of a Windows guest? Perhaps it's > a bug in the virtio-win drivers.
I'm reminded of the following RHBZs: https://bugzilla.redhat.com/show_bug.cgi?id=890648 [libvirt] https://bugzilla.redhat.com/show_bug.cgi?id=1122151 [qemu-kvm] Please refer especially to the QEMU commits listed in https://bugzilla.redhat.com/show_bug.cgi?id=890648#c22 namely e2ae6159de24 virtio-serial: report frontend connection state via monitor 32a97ea1711f char: report frontend open/closed state in 'query-chardev' This blurb could also be interesting (linked in <https://bugzilla.redhat.com/show_bug.cgi?id=890648#c20>): https://lists.gnu.org/archive/html/qemu-devel/2014-05/msg06366.html See also further work listed in: https://bugzilla.redhat.com/show_bug.cgi?id=1244064#c12 The relevant libvirt commits seem to be (some of them are linked in <https://bugzilla.redhat.com/show_bug.cgi?id=890648>): 24c25a68c21a conf: Add channel state for virtio channels to the XML 15bbaaf014d0 qemu: Add handling for VSERPORT_CHANGE event 4d7eb903119e qemu: chardev: Extract more information about character devices 21c676c2aa60 qemu: process: Refresh virtio channel guest state when connecting to mon 1a4609101b63 event: Add guest agent lifecycle event 4ca2744e8b8d examples: Add support for the guest agent lifecycle event b29f2436ac80 qemu: Emit the guest agent lifecycle event 2af51483cc2f processSerialChangedEvent: Close agent monitor early f1caa42777ff qemu: Close the agent connection only on agent channel events I'm guessing Matt's host-side component (which I assume is not libvirt) should imitate libvirt's logic here; that is, make use of the VSERPORT_CHANGE event, and/or invoke "query-chardev" and attend to the "frontend-open" field in the result. Don't start sending until query-chardev or VSERPORT_CHANGE reports that the (custom) agent has connected in the guest. Thanks Laszlo
