[libvirt] qemu: domain notification for serial channel changes

[Matt Broadstone]

On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa at redhat.com> 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=38c841420e325b6227b3bcd67a26a9b9560b487f;hb=HEAD#l4402),
>> > 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