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
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list