On Fri, Nov 11, 2016 at 5:58 AM, Daniel P. Berrange <berrange@xxxxxxxxxx> wrote: > On Fri, Nov 11, 2016 at 11:41:42AM +0100, Peter Krempa wrote: >> On Fri, Nov 11, 2016 at 10:33:11 +0000, Daniel Berrange wrote: >> > On Fri, Nov 11, 2016 at 11:27:07AM +0100, Peter Krempa wrote: >> > > On Fri, Nov 11, 2016 at 10:18:00 +0000, Daniel Berrange wrote: >> > > > On Fri, Nov 11, 2016 at 11:13:19AM +0100, Peter Krempa wrote: >> > > > > On Mon, Nov 07, 2016 at 15:48:35 -0500, Matt Broadstone wrote: >> > > > > > Presently domain events are emitted for the "agent lifecycle" which >> > > > > > is a specialization on virtio-serial events specific to the channel >> > > > > > named "org.qemu.guest_agent.0". This patch adds a generic event for >> > > > > > "channel lifecycles", which emit state change events for all >> > > > > > attached channels. >> > > > > > --- >> > > >> > > [...] >> >> > These events are not solely useful for knowing when to connect to the >> > channel. An application which relies on the QEMU guest agent because >> > of the libvirt API calls it makes, may wish to know when the guest >> > agent is running, so it can avoid making libvirt APIs that use it. >> > >> > eg, the app can disable the ability to quiesce filesystems until it >> > sees the event that the agent is running. >> > >> > So I don't really see the guest agent as so special that we must not >> > allow these events to be seen by apps - it just creates extra work >> > for apps to force them to pointlessly register two event callbacks. >> >> My point was that the guest agent may still be connected but >> disfunctional from libvirt's point of view. The Agent lifecycle callback >> should report this, while the channel callback should not. >> >> Such apps will need two callbacks anyways. > > It depends on what they wish to report. The QEMU guest agent is not the > only one that is special from an app POV too - the SPICE guest agent is > another one that apps cannot directly connect to, but which would still > report events via the channel lifecycle event. There may be others later > too, so I'm really not seeing a reason to special case the QEMU guest > agent in any way. > > Regards, > Daniel > -- > |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| > |: http://libvirt.org -o- http://virt-manager.org :| > |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :| I'm inclined to agree with Daniel here. Having a generic callback for all paths here doesn't actually adversely affect anything, and is arguably more "correct" in terms of reporting. Rather think of it this way: this current behavior accurately models what I see when monitoring the domstatus file. Matt -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list