On 11/20/2014 12:03 PM, Peter Krempa wrote:
@@ -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.
Ooh, you have a point - we might be able to report multiple states, such as: no agent connected (reasons include just booted, agent disconnect, ...) agent connected and idle (reasons include agent connect, last agent command completed, ...) agent busy (reasons include other libvirt API, qemu-agent-command backdoor API, ...) On the other hand, do we need to trigger an event for every state change like that? And virDomainEventRegisterAny() doesn't really provide a nice way for callers to filter which events they want (they have to filter on every callback for the events they are actually interested in). It's better to start with a small set of events, and add more if there is a good use case.
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? )
Yeah, I mentioned that in one of my replies to 9/11; I think the channel name is sufficient. -- Eric Blake eblake redhat com +1-919-301-3266 Libvirt virtualization library http://libvirt.org