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