[libvirt] [PATCH 11/11] qemu: Emit the guest agent lifecycle event

[Eric Blake]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 539 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20141120/5664952c/attachment-0001.sig>