Re: [Qemu-devel] virtio-serial guest agent channel timing requirements

Re: [Qemu-devel] virtio-serial guest agent channel timing requirements

[Stefan Hajnoczi]

On Fri, Nov 4, 2016 at 9:46 PM, Matt Broadstone <mbroadst@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.

Stefan

Re: [Qemu-devel] virtio-serial guest agent channel timing requirements

[Laszlo Ersek]

On 11/04/16 23:18, Stefan Hajnoczi wrote:
> On Fri, Nov 4, 2016 at 9:46 PM, Matt Broadstone <mbroadst@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