Re: [libvirt] qemu: domain notification for serial channel changes

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