summaryrefslogtreecommitdiff
path: root/QMP/qmp-events.txt
AgeCommit message (Collapse)AuthorFilesLines
2013-07-15net: add support of mac-programming over macvtap in QEMU sideAmos Kong1-0/+17
Currently macvtap based macvlan device is working in promiscuous mode, we want to implement mac-programming over macvtap through Libvirt for better performance. Design: QEMU notifies Libvirt when rx-filter config is changed in guest, then Libvirt query the rx-filter information by a monitor command, and sync the change to macvtap device. Related rx-filter config of the nic contains main mac, rx-mode items and vlan table. This patch adds a QMP event to notify management of rx-filter change, and adds a monitor command for management to query rx-filter information. Test: If we repeatedly add/remove vlan, and change macaddr of vlan interfaces in guest by a loop script. Result: The events will flood the QMP client(management), management takes too much resource to process the events. Event_throttle API (set rate to 1 ms) can avoid the events to flood QMP client, but it could cause an unexpected delay (~1ms), guests guests normally expect rx-filter updates immediately. So we use a flag for each nic to avoid events flooding, the event is emitted once until the query command is executed. The flag implementation could not introduce unexpected delay. There maybe exist an uncontrollable delay if we let Libvirt do the real change, guests normally expect rx-filter updates immediately. But it's another separate issue, we can investigate it when the work in Libvirt side is done. Michael S. Tsirkin: tweaked to enable events on start Michael S. Tsirkin: fixed not to crash when no id Michael S. Tsirkin: fold in patch: "additional fixes for mac-programming feature" Amos Kong: always notify QMP client if mactable is changed Amos Kong: return NULL list if no net client supports rx-filter query Reviewed-by: Eric Blake <eblake@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Signed-off-by: Amos Kong <akong@redhat.com> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-06-07correct RTC_CHANGE_EVENT description (v2)Marcelo Tosatti1-1/+2
Fix RTC_CHANGE event description to match implementation. Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2013-04-30add a new qevent: QEVENT_GUEST_PANICKEDHu Tao1-0/+14
This event will be emited when qemu detects guest panic. Signed-off-by: Wen Congyang <wency@cn.fujitsu.com> Signed-off-by: Hu Tao <hutao@cn.fujitsu.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Message-id: cf0bc45ecf9ecd3699bc72dc39f8cbab8ed79d8c.1366945969.git.hutao@cn.fujitsu.com Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-03-26qmp: add path to device_deleted eventMichael S. Tsirkin1-1/+3
Add QOM path to device deleted event. It now becomes useful to report it for devices which don't have an ID assigned. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2013-03-17qdev: DEVICE_DELETED eventMichael S. Tsirkin1-0/+16
libvirt has a long-standing bug: when removing the device, it can request removal but does not know when the removal completes. Add an event so we can fix this in a robust way. Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
2012-10-24block: introduce BLOCK_JOB_READY eventPaolo Bonzini1-0/+18
Even for jobs that need to be manually completed, management may want to take care itself of the completion, not requiring the user to issue a command to terminate the job. In this case we want to avoid that they poll us continuously, waiting for completion to become available. Thus, add a new event that signals the phase switch and the availability of the block-job-complete command. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-09-28block: introduce block job errorPaolo Bonzini1-0/+22
The following behaviors are possible: 'report': The behavior is the same as in 1.1. An I/O error, respectively during a read or a write, will complete the job immediately with an error code. 'ignore': An I/O error, respectively during a read or a write, will be ignored. For streaming, the job will complete with an error and the backing file will be left in place. For mirroring, the sector will be marked again as dirty and re-examined later. 'stop': The job will be paused and the job iostatus will be set to failed or nospace, while the VM will keep running. This can only be specified if the block device has rerror=stop and werror=stop or enospc. 'enospc': Behaves as 'stop' for ENOSPC errors, 'report' for others. In all cases, even for 'report', the I/O error is reported as a QMP event BLOCK_JOB_ERROR, with the same arguments as BLOCK_IO_ERROR. It is possible that while stopping the VM a BLOCK_IO_ERROR event will be reported and will clobber the event from BLOCK_JOB_ERROR, or vice versa. This is not really avoidable since stopping the VM completes all pending I/O requests. In fact, it is already possible now that a series of BLOCK_IO_ERROR events are reported with rerror=stop, because vm_stop calls bdrv_drain_all and this can generate further errors. Signed-off-by: Paolo Bonzini <pbonzini@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-09-28QAPI: add command for live block commit, 'block-commit'Jeff Cody1-2/+4
The command for live block commit is added, which has the following arguments: device: the block device to perform the commit on (mandatory) base: the base image to commit into; optional (if not specified, it is the underlying original image) top: the top image of the commit - all data from inside top down to base will be committed into base (mandatory for now; see note, below) speed: maximum speed, in bytes/sec Note: Eventually this command will support merging down the active layer, but that code is not yet complete. If the active layer is passed in as top, then an error will be returned. Once merging down the active layer is supported, the 'top' argument may become optional, and default to the active layer. The is done as a block job, so upon completion a BLOCK_JOB_COMPLETED will be emitted. Signed-off-by: Jeff Cody <jcody@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-08-13qmp: add SUSPEND_DISK eventLuiz Capitulino1-0/+14
Emitted when the guest makes a request to enter S4 state. There are three possible ways of having this event, as described here: http://lists.gnu.org/archive/html/qemu-devel/2012-07/msg02307.html I've decided to add a new event and make it indepedent of SHUTDOWN. This means that the SHUTDOWN event will eventually follow the SUSPEND_DISK event. I've choosen this way because of two reasons: 1. Having an indepedent event makes it possible to query for its existence by using query-events 2. In the future, we may allow the user to change what QEMU should do as a result of the guest entering S4. So it's a good idea to keep both events separated Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-08-13qmp: qmp-events.txt: add missing doc for the SUSPEND eventLuiz Capitulino1-0/+12
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2012-08-13qmp: qmp-events.txt: put events in alphabetical orderLuiz Capitulino1-136/+130
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Eric Blake <eblake@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2012-08-13qmp: emit the WAKEUP event when the guest is put to runLuiz Capitulino1-0/+13
Today, the WAKEUP event is emitted when a wakeup _request_ is made. This could be the system_wakeup command, for example. A better semantic would be to emit the event when the guest is already running, as that's what matters in the end. This commit does that change. In theory, this could break compatibility. In practice, it shouldn't happen though, as clients shouldn't rely on timing characteristics of the events. That is, a client relying that the guest is not running when the event arrives may break if the event arrives after the guest is already running. This commit also adds the missing documentation for the WAKEUP event. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Acked-by: Gerd Hoffmann <kraxel@redhat.com>
2012-06-15Add event notification for guest balloon changesDaniel P. Berrange1-0/+18
After setting a balloon target value, applications have to continually poll 'query-balloon' to determine whether the guest has reacted to this request. The virtio-balloon backend knows exactly when the guest has reacted though, and thus it is possible to emit a JSON event to tell the mgmt application whenever the guest balloon changes. This introduces a new 'qemu_balloon_changed()' API which is to be called by balloon driver backends, whenever they have a change in balloon value. This takes the 'actual' balloon value, as would be found in the BalloonInfo struct. The qemu_balloon_change API emits a JSON monitor event which looks like: {"timestamp": {"seconds": 1337162462, "microseconds": 814521}, "event": "BALLOON_CHANGE", "data": {"actual": 944766976}} * balloon.c, balloon.h: Introduce qemu_balloon_changed() for emitting balloon change events on the monitor * hw/virtio-balloon.c: Invoke qemu_balloon_changed() whenever the guest changes the balloon actual value * monitor.c, monitor.h: Define QEVENT_BALLOON_CHANGE Signed-off-by: Daniel P. Berrange <berrange@redhat.com> Acked-by: Amit Shah <amit.shah@redhat.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2012-02-22qmp: add DEVICE_TRAY_MOVED eventLuiz Capitulino1-0/+18
It's emitted whenever the tray is moved by the guest or by HMP/QMP commands. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Reviewed-by: Markus Armbruster <armbru@redhat.com> Acked-by: Kevin Wolf <kwolf@redhat.com>
2012-01-26qmp: add block_job_cancel commandStefan Hajnoczi1-0/+24
Add block_job_cancel, which stops an active block streaming operation. When the operation has been cancelled the new BLOCK_JOB_CANCELLED event is emitted. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2012-01-26qmp: add block_stream commandStefan Hajnoczi1-0/+29
Add the block_stream command, which starts copy backing file contents into the image file. Also add the BLOCK_JOB_COMPLETED QMP event which is emitted when image streaming completes. Later patches add control over the background copy speed, cancelation, and querying running streaming operations. Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2011-12-02fix spelling in QMP sub directoryDong Xu Wang1-1/+1
Cc: Markus Armbruster <armbru@redhat.com> Acked-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Dong Xu Wang <wdongxu@linux.vnet.ibm.com> Signed-off-by: Stefan Hajnoczi <stefanha@linux.vnet.ibm.com>
2010-12-09spice: connection events.Gerd Hoffmann1-0/+64
This patch adds support for connection events to spice. The events are quite simliar to the vnc events. Unlike vnc spice uses multiple tcp channels though. qemu will report every single tcp connection (aka spice channel). If you want track spice sessions only you can filter for the main channel (channel-type == 1). Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
2010-10-22Trivial fix for QMP/qmp-events.txtHidetoshi Seto1-1/+1
Fix example of STOP event that was just copy-and-pasted. Signed-off-by: Hidetoshi Seto <seto.hidetoshi@jp.fujitsu.com> Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2010-05-03QMP: Introduce RESUME eventLuiz Capitulino1-0/+12
It's emitted when the Virtual Machine resumes execution. We currently have the STOP event but don't have the matching RESUME one, this means that clients are notified when the VM is stopped but don't get anything when it resumes. Let's fix that as it's already causing some trouble to libvirt. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-04-18QMP: Improve RTC_CHANGE event descriptionLuiz Capitulino1-1/+1
Some people might think that this event is emitted whenever the time changes, be more specific. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com>
2010-03-09QMP: Introduce WATCHDOG eventLuiz Capitulino1-0/+19
It's emitted whenever the watchdog device's timer expires. The action taken is provided in the 'data' member. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-03-08QMP: Introduce RTC_CHANGE eventLuiz Capitulino1-0/+15
Emitted whenever the RTC time changes. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-03-08QMP: Revamp the qmp-events.txt fileLuiz Capitulino1-37/+133
Now we can say it's useful, the following changes have been made: - Put events in alphabetical order - Add examples to all events - Document all 'data' members - Small corrections and cleanups Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-03-08QMP: Drop DEBUG eventLuiz Capitulino1-6/+0
This event has been introduced in the first round of QMP commits, turns out that it's based on the usage of the EXCP_DEBUG macro, which has discussable semantics when exposed through QMP. As libvirt doesn't use this, let's just drop it. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-02-10QMP: BLOCK_IO_ERROR event handlingLuiz Capitulino1-0/+21
This commit adds the basic definitions for the BLOCK_IO_ERROR event, but actual event emission will be introduced by the next commits. Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-19QMP: Introduce VNC_INITIALIZED eventLuiz Capitulino1-0/+6
It's emitted when a VNC client session is activated by QEMU, client's information such as port, IP and auth ID (if the session is authenticated) are provided. Event example: { "event": "VNC_INITIALIZED", "timestamp": {"seconds": 1263475302, "microseconds": 150772}, "data": { "server": { "auth": "sasl", "family": "ipv4", "service": "5901", "host": "0.0.0.0"}, "client": { "family": "ipv4", "service": "46089", "host": "127.0.0.1", "sasl_username": "lcapitulino" } } } Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-19QMP: Introduce VNC_DISCONNECTED eventLuiz Capitulino1-0/+6
It's emitted when a VNC client disconnects from QEMU, client's information such as port and IP address are provided. Event example: { "event": "VNC_DISCONNECTED", "timestamp": { "seconds": 1262976601, "microseconds": 975795 }, "data": { "server": { "auth": "sasl", "family": "ipv4", "service": "5901", "host": "0.0.0.0" }, "client": { "family": "ipv4", "service": "58425", "host": "127.0.0.1", "sasl_username": "foo" } } } Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2010-01-19QMP: Introduce VNC_CONNECTED eventLuiz Capitulino1-0/+7
It's emitted when a VNC client connects to QEMU, client's information such as port and IP address are provided. Note that this event is emitted right when the connection is established. This means that it happens before authentication procedure and session initialization. Event example: { "event": "VNC_CONNECTED", "timestamp": { "seconds": 1262976601, "microseconds": 975795 }, "data": { "server": { "auth": "sasl", "family": "ipv4", "service": "5901", "host": "0.0.0.0" }, "client": { "family": "ipv4", "service": "58425", "host": "127.0.0.1" } } } Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2009-12-03QMP: Introduce qmp-events.txtLuiz Capitulino1-0/+26
Signed-off-by: Luiz Capitulino <lcapitulino@redhat.com> Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>