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