On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: > Hi, > > I was in the process of implementing a custom qemu agent which > communicates over virtio-serial channels, when I noticed that the only > way to receive channel state change notifications was to poll the > domstatus XML file. There does seem to be code in libvirt to monitor > for serial change events > (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=...), > however it's hardcoded/specific to the qemu-ga (explicitly checking > for ports named "org.qemu.guest_agent.0"). > > It occurs to me that while there was a class of events added for guest > lifecycle changes, it might be a more generic solution to provide > events for character device changes. Am I missing some existing > functionality here? I'm a first-time poster here so I was hoping to > both signal my intent to implement something more generic, as well as > ping the community to see if there would be interest in this work or > reasons why I shouldn't be doing this. Yes, having that previous event tied to just the QEMU guest agent looks like a mistake to me. We should have a general lifecycle evnt for channel devices. It would basically be the same as the guest agent lifecycle event, but would include the port name, so you can distinguish events from different channels.

On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa(a)redhat.com&gt; wrote: > On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote: >> On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: >> > Hi, >> > >> > I was in the process of implementing a custom qemu agent which >> > communicates over virtio-serial channels, when I noticed that the only >> > way to receive channel state change notifications was to poll the >> > domstatus XML file. There does seem to be code in libvirt to monitor >> > for serial change events >> > (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=...), >> > however it's hardcoded/specific to the qemu-ga (explicitly checking >> > for ports named "org.qemu.guest_agent.0"). >> > >> > It occurs to me that while there was a class of events added for guest >> > lifecycle changes, it might be a more generic solution to provide >> > events for character device changes. Am I missing some existing >> > functionality here? I'm a first-time poster here so I was hoping to >> > both signal my intent to implement something more generic, as well as >> > ping the community to see if there would be interest in this work or >> > reasons why I shouldn't be doing this. >> >> Yes, having that previous event tied to just the QEMU guest agent looks >> like a mistake to me. We should have a general lifecycle evnt for >> channel devices. It would basically be the same as the guest agent >> lifecycle event, but would include the port name, so you can distinguish >> events from different channels. > > That choice was deliberate. I planned to add a separate event for > channels but never got around to do it actually. The guest agent event > is separate since libvirt can have different handling regarding the > guest agent state and I did not want to mix them. > > Peter Daniel, Peter, Thanks for your quick responses. I have a few questions before implementation: - I assume that you would prefer to keep the existing guest lifecycle events, for backwards compatibility? - Do you have a preference wrt naming this event? I see some inconsistencies the events ids (design-wise) (e.g. VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a single event for all potential changes like VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE). Matt

On Mon, Nov 07, 2016 at 08:56:58 -0500, Matt Broadstone wrote: > On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone <mbroadst(a)gmail.com&gt; wrote: > > On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa(a)redhat.com&gt; wrote: > >> On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote: > >>> On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote: [...] > >> > >> That choice was deliberate. I planned to add a separate event for > >> channels but never got around to do it actually. The guest agent event > >> is separate since libvirt can have different handling regarding the > >> guest agent state and I did not want to mix them. > >> > >> Peter > > > > Daniel, Peter, > > > > Thanks for your quick responses. I have a few questions before implementation: > > > > - I assume that you would prefer to keep the existing guest > > lifecycle events, for backwards compatibility? > > > > - Do you have a preference wrt naming this event? I see some > > inconsistencies the events ids (design-wise) (e.g. > > VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED > > / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a > > single event for all potential changes like > > VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE). A single event is preferred. Multiple names regarding the device lifecycle are a result of iterative adding of events over a long time. > > > > Matt > > Ah, sorry one followup question. Should the event generalize to serial > changes, or is the preference to keep it specific to channels? Qemu currently implements this for virtio channels, thus it will work currently only for channels. The design of the data returned by the event may allow to use other devices like 'serial'. The difference is that a serial device uses port number as the target, whereas channel uses channel name.