On 11/20/14 20:01, Eric Blake wrote:
On 11/19/2014 03:23 AM, Peter Krempa wrote:
> Add code to emit the event on change of the channel state and reconnect
> to the qemu process.
> ---
> src/qemu/qemu_driver.c | 5 +++++
> src/qemu/qemu_process.c | 13 ++++++++++---
> 2 files changed, 15 insertions(+), 3 deletions(-)
>
> @@ -4369,6 +4370,10 @@ processSerialChangedEvent(virQEMUDriverPtr driver,
> dev.data.chr->targetType != VIR_DOMAIN_CHR_CHANNEL_TARGET_TYPE_VIRTIO)
> goto endjob;
>
> + if (STREQ_NULLABLE(dev.data.chr->target.name,
"org.qemu.guest_agent.0") &&
> + (event = virDomainEventAgentLifecycleNewFromObj(vm, newstate, 0)))
> + qemuDomainEventQueue(driver, event);
> +
See my comments on 9/11 - I think that filtering this event to just the
org.qemu.guest_agent.0 channel is wrong. That may be the only channel
that libvirt specifically cares about for tracking whether we can send
guest agent commands, but it is not the only channel that management may
care about. In fact, naming it virDomainEventAgentLifecycle* may be
misleading; isn't it really about virDomainEventChannelLifecycle (where
guest-agent is just one use of a channel)?
I specifically wanted to shoot for agent events as they may be used also
in a different way than just connect/disconnect. If we want to report
state of channels too I have a partially finished patch that allows to
do that.
The callback prototype then needs to be different as we need to pass
also the channel name and possibly other data to identify the channel
(and/or serial port? )
Peter