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