[libvirt] qemu: domain notification for serial channel changes
Hi, I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38c...), however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0"). It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this. Regards, Matt
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
Hi,
I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38c...), however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0").
It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this.
Yes, having that previous event tied to just the QEMU guest agent looks like a mistake to me. We should have a general lifecycle evnt for channel devices. It would basically be the same as the guest agent lifecycle event, but would include the port name, so you can distinguish events from different channels. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote:
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
Hi,
I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38c...), however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0").
It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this.
Yes, having that previous event tied to just the QEMU guest agent looks like a mistake to me. We should have a general lifecycle evnt for channel devices. It would basically be the same as the guest agent lifecycle event, but would include the port name, so you can distinguish events from different channels.
That choice was deliberate. I planned to add a separate event for channels but never got around to do it actually. The guest agent event is separate since libvirt can have different handling regarding the guest agent state and I did not want to mix them. Peter
On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote:
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
Hi,
I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38c...), however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0").
It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this.
Yes, having that previous event tied to just the QEMU guest agent looks like a mistake to me. We should have a general lifecycle evnt for channel devices. It would basically be the same as the guest agent lifecycle event, but would include the port name, so you can distinguish events from different channels.
That choice was deliberate. I planned to add a separate event for channels but never got around to do it actually. The guest agent event is separate since libvirt can have different handling regarding the guest agent state and I did not want to mix them.
Peter
Daniel, Peter, Thanks for your quick responses. I have a few questions before implementation: - I assume that you would prefer to keep the existing guest lifecycle events, for backwards compatibility? - Do you have a preference wrt naming this event? I see some inconsistencies the events ids (design-wise) (e.g. VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a single event for all potential changes like VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE). Matt
On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone <mbroadst@gmail.com> wrote:
On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote:
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
Hi,
I was in the process of implementing a custom qemu agent which communicates over virtio-serial channels, when I noticed that the only way to receive channel state change notifications was to poll the domstatus XML file. There does seem to be code in libvirt to monitor for serial change events (https://libvirt.org/git/?p=libvirt.git;a=blob;f=src/qemu/qemu_driver.c;h=38c...), however it's hardcoded/specific to the qemu-ga (explicitly checking for ports named "org.qemu.guest_agent.0").
It occurs to me that while there was a class of events added for guest lifecycle changes, it might be a more generic solution to provide events for character device changes. Am I missing some existing functionality here? I'm a first-time poster here so I was hoping to both signal my intent to implement something more generic, as well as ping the community to see if there would be interest in this work or reasons why I shouldn't be doing this.
Yes, having that previous event tied to just the QEMU guest agent looks like a mistake to me. We should have a general lifecycle evnt for channel devices. It would basically be the same as the guest agent lifecycle event, but would include the port name, so you can distinguish events from different channels.
That choice was deliberate. I planned to add a separate event for channels but never got around to do it actually. The guest agent event is separate since libvirt can have different handling regarding the guest agent state and I did not want to mix them.
Peter
Daniel, Peter,
Thanks for your quick responses. I have a few questions before implementation:
- I assume that you would prefer to keep the existing guest lifecycle events, for backwards compatibility?
- Do you have a preference wrt naming this event? I see some inconsistencies the events ids (design-wise) (e.g. VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a single event for all potential changes like VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE).
Matt
Ah, sorry one followup question. Should the event generalize to serial changes, or is the preference to keep it specific to channels? Matt
On Mon, Nov 07, 2016 at 08:56:58 -0500, Matt Broadstone wrote:
On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone <mbroadst@gmail.com> wrote:
On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote:
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
[...]
That choice was deliberate. I planned to add a separate event for channels but never got around to do it actually. The guest agent event is separate since libvirt can have different handling regarding the guest agent state and I did not want to mix them.
Peter
Daniel, Peter,
Thanks for your quick responses. I have a few questions before implementation:
- I assume that you would prefer to keep the existing guest lifecycle events, for backwards compatibility?
- Do you have a preference wrt naming this event? I see some inconsistencies the events ids (design-wise) (e.g. VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a single event for all potential changes like VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE).
A single event is preferred. Multiple names regarding the device lifecycle are a result of iterative adding of events over a long time.
Matt
Ah, sorry one followup question. Should the event generalize to serial changes, or is the preference to keep it specific to channels?
Qemu currently implements this for virtio channels, thus it will work currently only for channels. The design of the data returned by the event may allow to use other devices like 'serial'. The difference is that a serial device uses port number as the target, whereas channel uses channel name. Having a universal event would require to use a discriminator along with a naming scheme for the numberred serial ports. Peter
On Mon, Nov 07, 2016 at 03:05:24PM +0100, Peter Krempa wrote:
On Mon, Nov 07, 2016 at 08:56:58 -0500, Matt Broadstone wrote:
On Mon, Nov 7, 2016 at 8:52 AM, Matt Broadstone <mbroadst@gmail.com> wrote:
On Mon, Nov 7, 2016 at 8:35 AM, Peter Krempa <pkrempa@redhat.com> wrote:
On Mon, Nov 07, 2016 at 13:31:30 +0000, Daniel Berrange wrote:
On Mon, Nov 07, 2016 at 08:22:59AM -0500, Matt Broadstone wrote:
[...]
That choice was deliberate. I planned to add a separate event for channels but never got around to do it actually. The guest agent event is separate since libvirt can have different handling regarding the guest agent state and I did not want to mix them.
Peter
Daniel, Peter,
Thanks for your quick responses. I have a few questions before implementation:
- I assume that you would prefer to keep the existing guest lifecycle events, for backwards compatibility?
- Do you have a preference wrt naming this event? I see some inconsistencies the events ids (design-wise) (e.g. VIR_DOMAIN_EVENT_ID_DEVICE_ADDED / VIR_DOMAIN_EVENT_ID_DEVICE_REMOVED / VIR_DOMAIN_EVENT_ID_DEVICE_DEVICE_REMOVAL_FAILED, instead of a single event for all potential changes like VIR_DOMAIN_EVENT_ID_AGENT_LIFECYCLE).
A single event is preferred. Multiple names regarding the device lifecycle are a result of iterative adding of events over a long time.
Matt
Ah, sorry one followup question. Should the event generalize to serial changes, or is the preference to keep it specific to channels?
Qemu currently implements this for virtio channels, thus it will work currently only for channels.
The design of the data returned by the event may allow to use other devices like 'serial'. The difference is that a serial device uses port number as the target, whereas channel uses channel name.
AFAIK, it is impossible to implement this event for anything other than virtio-channels. With serial port emulation there's no way for QEMU to know whether the guest OS has the port open or not - the concept only exists in the virtio-serial device model. Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://entangle-photo.org -o- http://search.cpan.org/~danberr/ :|
participants (3)
-
Daniel P. Berrange -
Matt Broadstone -
Peter Krempa