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)?
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library
http://libvirt.org