qemu-ga: support for sending events

Events can play an integral role when monitoring internal state of the guest OS. This patch adds the core functionality for adding events to QEMU Guest Agent.

Quoted 3 lines · Tomáš Golembiovský

Events can play an integral role when monitoring internal state of the guest OS. This patch adds the core functionality for adding events to QEMU Guest Agent.

Will sending events confuse existing clients that aren't expecting them? Do we need to add some sort of protocol handshake when the client first connects so that we know whether the client is able to parse events (including ignoring unknown events)? (It's a shame that events were built into QMP from the beginning, so we've never had to figure out how to portably hand-shake a client/server negotiation on additional features to be used across the wire)

Signature · 4 lines

-- 
Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org

This is just a draft, or a request for comments if you will.

This patch sets drafts the support of sending events by QEMU Guest Agent. Events can plan important role in monitoring of the guest OS behaviour. The range of use cases ranges from events important for scheduling, e.g. memory and
CPU usage statistics, to things like changes to IP addresses on network interfaces to for example changes in the list of active users.

For now the patch set adds single periodic callback function to the GA main loop that can perform checks and trigger events that have occured since previous run of the callback.

We can of course take it one step further and add a general framwork for periodically running any of the already implemented commands. Add a function
that would maintain a list of registered checks. Client would use some command
(register-monitor-command) passing it a command name and timeout in seconds and
the monitoring handler would then run the specified command and report the result... or report only if the return value changed since previous invocation.
This feature would remove part of the communication overhead between client and
GA.

So before I invest any more time in either of these approaches, tell me. Would
somethign like this be wanted or is that too controversial? Any other thoughts
and ideas?

qemu-ga: add support for events
qemu-ga: add simple event reporting memory statistics
qemu-ga: add support for periodic command runner

 Makefile               |  7 +++-
 qga/Makefile.objs      |  2 +-
 qga/channel-posix.c    |  8 +++++
 qga/channel-win32.c    |  6 ++++
 qga/channel.h          |  1 +
 qga/guest-agent-core.h |  1 +
 qga/main.c             | 98
++++++++++++++++++++++++++++++++++++++++++++++++++
 qga/qapi-event.json    | 35 ++++++++++++++++++
 qga/qapi-schema.json   |  2 ++
 9 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 qga/qapi-event.json

--
2.13.1

--

Hi

Quoted 27 lines · Tomáš Golembiovský

This is just a draft, or a request for comments if you will.

This patch sets drafts the support of sending events by QEMU Guest Agent. Events can plan important role in monitoring of the guest OS behaviour. The range of use cases ranges from events important for scheduling, e.g. memory and
CPU usage statistics, to things like changes to IP addresses on network interfaces to for example changes in the list of active users.

For now the patch set adds single periodic callback function to the GA main loop that can perform checks and trigger events that have occured since previous run of the callback.

We can of course take it one step further and add a general framwork for periodically running any of the already implemented commands. Add a function
that would maintain a list of registered checks. Client would use some command
(register-monitor-command) passing it a command name and timeout in seconds and
the monitoring handler would then run the specified command and report the result... or report only if the return value changed since previous invocation.
This feature would remove part of the communication overhead between client and
GA.

Quoted 7 lines

So before I invest any more time in either of these approaches, tell me. Would
somethign like this be wanted or is that too controversial? Any other thoughts
and ideas?

It doesn't feel wrong, but Is there really too much overhead and/or latency if a request is periodic from the client? ie did you do some measurements before coming to this proposal?

Tomáš Golembiovský (3):

Quoted 17 lines

qemu-ga: add support for events
qemu-ga: add simple event reporting memory statistics
qemu-ga: add support for periodic command runner

 Makefile               |  7 +++-
 qga/Makefile.objs      |  2 +-
 qga/channel-posix.c    |  8 +++++
 qga/channel-win32.c    |  6 ++++
 qga/channel.h          |  1 +
 qga/guest-agent-core.h |  1 +
 qga/main.c             | 98
++++++++++++++++++++++++++++++++++++++++++++++++++
 qga/qapi-event.json    | 35 ++++++++++++++++++
 qga/qapi-schema.json   |  2 ++
 9 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 qga/qapi-event.json

Quoted 5 lines

--
2.13.1

Marc-André Lureau

Hi,

Quoted 39 lines · On Fri, 23 Jun 2017 13:25:34 +0000 Marc-André Lureau…

Hi

Quoted 27 lines · Tomáš Golembiovský

This is just a draft, or a request for comments if you will.

This patch sets drafts the support of sending events by QEMU Guest Agent. Events can plan important role in monitoring of the guest OS behaviour. The range of use cases ranges from events important for scheduling, e.g. memory and
CPU usage statistics, to things like changes to IP addresses on network interfaces to for example changes in the list of active users.

For now the patch set adds single periodic callback function to the GA main loop that can perform checks and trigger events that have occured since previous run of the callback.

We can of course take it one step further and add a general framwork for periodically running any of the already implemented commands. Add a function
that would maintain a list of registered checks. Client would use some command
(register-monitor-command) passing it a command name and timeout in seconds and
the monitoring handler would then run the specified command and report the result... or report only if the return value changed since previous invocation.
This feature would remove part of the communication overhead between client and
GA.

Quoted 7 lines

So before I invest any more time in either of these approaches, tell me. Would
somethign like this be wanted or is that too controversial? Any other thoughts
and ideas?

Quoted 3 lines

It doesn't feel wrong, but Is there really too much overhead and/or latency if a request is periodic from the client? ie did you do some measurements before coming to this proposal?

No, I didn't do any measurements. And it may be even true that in the grand scheme of things the overhead/latency may be insignificant, if we imagine a client that repeatedly calls about 5 to 10 commands every 5 or 10 seconds. Still, it just feels like a more correct approach to me. But that may be just my feeling, that's why I brought this to the list to get the opinion of others.

Quoted 26 lines

Tomáš Golembiovský (3):

Quoted 17 lines

qemu-ga: add support for events
qemu-ga: add simple event reporting memory statistics
qemu-ga: add support for periodic command runner

 Makefile               |  7 +++-
 qga/Makefile.objs      |  2 +-
 qga/channel-posix.c    |  8 +++++
 qga/channel-win32.c    |  6 ++++
 qga/channel.h          |  1 +
 qga/guest-agent-core.h |  1 +
 qga/main.c             | 98
++++++++++++++++++++++++++++++++++++++++++++++++++
 qga/qapi-event.json    | 35 ++++++++++++++++++
 qga/qapi-schema.json   |  2 ++
 9 files changed, 158 insertions(+), 2 deletions(-)
 create mode 100644 qga/qapi-event.json

Quoted 5 lines

--
2.13.1

Marc-André Lureau

Signature · 1 line

Tomáš Golembiovský <[email protected]>

This is just a draft, or a request for comments if you will.

This patch sets drafts the support of sending events by QEMU Guest Agent. Events can plan important role in monitoring of the guest OS behaviour. The range of use cases ranges from events important for scheduling, e.g. memory and CPU usage statistics, to things like changes to IP addresses on network interfaces to for example changes in the list of active users.

For now the patch set adds single periodic callback function to the GA main loop that can perform checks and trigger events that have occured since previous run of the callback.

We can of course take it one step further and add a general framwork for periodically running any of the already implemented commands. Add a function that would maintain a list of registered checks. Client would use some command (register-monitor-command) passing it a command name and timeout in seconds and the monitoring handler would then run the specified command and report the result... or report only if the return value changed since previous invocation. This feature would remove part of the communication overhead between client and GA.

So before I invest any more time in either of these approaches, tell me. Would somethign like this be wanted or is that too controversial? Any other thoughts and ideas?

Quoted 11 lines · Tomáš Golembiovský

This is just a draft, or a request for comments if you will.

This patch sets drafts the support of sending events by QEMU Guest Agent. Events can plan important role in monitoring of the guest OS behaviour. The range of use cases ranges from events important for scheduling, e.g. memory and CPU usage statistics, to things like changes to IP addresses on network interfaces to for example changes in the list of active users.

For now the patch set adds single periodic callback function to the GA main loop that can perform checks and trigger events that have occured since previous run of the callback.

How do we guarantee that the guest cannot flood qemu with too many events?

Obviously, qga is already used where we (in general) trust the guest to not be malicious, but we still have to assume that a guest can be compromised, and will try to abuse qga to escape to an attack against qemu.

Quoted 14 lines

We can of course take it one step further and add a general framwork for periodically running any of the already implemented commands. Add a function that would maintain a list of registered checks. Client would use some command (register-monitor-command) passing it a command name and timeout in seconds and the monitoring handler would then run the specified command and report the result... or report only if the return value changed since previous invocation. This feature would remove part of the communication overhead between client and GA.

So before I invest any more time in either of these approaches, tell me. Would somethign like this be wanted or is that too controversial? Any other thoughts and ideas?

Signature · 3 lines

Eric Blake, Principal Software Engineer
Red Hat, Inc.           +1-919-301-3266
Virtualization:  qemu.org | libvirt.org