- 28 4月, 2012 1 次提交
-
-
由 Eric Blake 提交于
With RHEL 6.2, virDomainBlockPull(dom, dev, bandwidth, 0) has a race with non-zero bandwidth: there is a window between the block_stream and block_job_set_speed monitor commands where an unlimited amount of data was let through, defeating the point of a throttle. This race was first identified in commit a9d3495e, and libvirt was able to reduce the size of the window for that race. In the meantime, the qemu developers decided to fix things properly; per this message: https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg03793.html the fix will be in qemu 1.1, and changes block-job-set-speed to use a different parameter name, as well as adding a new optional parameter to block-stream, which eliminates the race altogether. Since our documentation already mentioned that we can refuse a non-zero bandwidth for some hypervisors, I think the best solution is to do just that for RHEL 6.2 qemu, so that the race is obvious to the user (anyone using stock RHEL 6.2 binaries won't have this patch, and anyone building their own libvirt with this patch for RHEL can also rebuild qemu to get the modern semantics, so it is no real loss in behavior). Meanwhile the code must be fixed to honor actual qemu 1.1 naming. Rename the parameter to 'modern', since the naming difference now covers more than just 'async' block-job-cancel. And while at it, fix an unchecked integer overflow. * src/qemu/qemu_monitor.h (enum BLOCK_JOB_CMD): Drop unused value, rename enum to match conventions. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Reflect enum rename. * src/qemu_qemu_monitor_json.h (qemuMonitorJSONBlockJob): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJob): Likewise, and support difference between RHEL 6.2 and qemu 1.1 block pull. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Reject bandwidth during pull with too-old qemu. * src/libvirt.c (virDomainBlockPull, virDomainBlockRebase): Document this.
-
- 12 4月, 2012 2 次提交
-
-
由 Eric Blake 提交于
In my testing, I was able to provoke an odd block pull failure: $ virsh blockpull dom vda --bandwidth 10000 error: Requested operation is not valid: No active operation on device: drive-virtio-disk0 merely by using gdb to artifically wait to do the block job set speed until after the pull had already finished. But in reality, that should be a success, since the pull finished before we had a chance to set speed. Furthermore, using a double job lock is not only annoying, but a bug in itself - if you do parallel virDomainBlockRebase, and hit the race window just right, the first call grabs the VM job to start a fast block job, then the second call grabs the VM job to start a long-running job with unspecified speed, then the first call finally regrabs the VM job and sets the speed, which ends up running the second job under the speed from the first call. By consolidating things into a single job, we avoid opening that race, as well as reduce the time between starting the job and changing the speed, for less likelihood of the speed change happening after block job completion in the first place. * src/qemu/qemu_monitor.h (BLOCK_JOB_CMD): Add new mode. * src/qemu/qemu_driver.c (qemuDomainBlockRebase): Move secondary job call... (qemuDomainBlockJobImpl): ...here, for fewer locks. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJob): Change return value on new internal mode.
-
由 Eric Blake 提交于
RHEL 6.2 was released with an early version of block jobs, which only worked on the qed file format, where the commands were spelled with underscore (contrary to QMP style), and where 'block_job_cancel' was synchronous and did not trigger an event. The upcoming qemu 1.1 release has fixed these short-comings [1][2]: the commands now work on multiple file types, are spelled with dash, and 'block-job-cancel' is asynchronous and emits an event upon conclusion. [1]qemu commit 370521a1d6f5537ea7271c119f3fbb7b0fa57063 [2]https://lists.gnu.org/archive/html/qemu-devel/2012-04/msg01248.html This patch recognizes the new spellings, and fixes virDomainBlockRebase to give a graceful error when talking to a too-old qemu on a partial rebase attempt. Fixes for the new semantics will come later. This patch also removes a bogus ATTRIBUTE_NONNULL mistakenly added in commit 10ec36e2. * src/qemu/qemu_capabilities.h (QEMU_CAPS_BLOCKJOB_SYNC) (QEMU_CAPS_BLOCKJOB_ASYNC): New bits. * src/qemu/qemu_capabilities.c (qemuCaps): Name them. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONCheckCommands): Set them. (qemuMonitorJSONBlockJob): Manage both command names. (qemuMonitorJSONDiskSnapshot): Minor formatting fix. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob): Alter signature. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJob): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Pass through capability bit. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Update callers.
-
- 24 3月, 2012 2 次提交
-
-
由 Eric Blake 提交于
The oVirt developers have stated that the real reasons they want to have qemu reuse existing volumes when creating a snapshot are: 1. the management framework is set up so that creation has to be done from a central node for proper resource tracking, and having libvirt and/or qemu create things violates the framework, and 2. qemu defaults to creating snapshots with an absolute path to the backing file, but oVirt wants to manage a backing chain that uses just relative names, to allow for easier migration of a chain across storage locations. When 0.9.10 added VIR_DOMAIN_SNAPSHOT_CREATE_REUSE_EXT (commit 4e9953a4), it only addressed point 1, but libvirt was still using O_TRUNC which violates point 2. Meanwhile, the new qemu 'transaction' monitor command includes a new optional mode argument that will force qemu to reuse the metadata of the file it just opened (with the burden on the caller to have valid metadata there in the first place). So, this tweaks the meaning of the flag to cover both points as intended for use by oVirt. It is not strictly backward-compatible to 0.9.10 behavior, but it can be argued that the O_TRUNC of 0.9.10 was a bug. Note that this flag is all-or-nothing, and only selects between 'existing' and the default 'absolute-paths'. A more flexible approach that would allow per-disk selections, as well as adding support for the 'no-backing-file' mode, would be possible by extending the <domainsnapshot> xml to have a per-disk mode, but until we have a management application expressing a need for that additional complexity, it is not worth doing. * src/libvirt.c (virDomainSnapshotCreateXML): Tweak documentation. * src/qemu/qemu_monitor.h (qemuMonitorDiskSnapshot): Add parameters. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDiskSnapshot): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorDiskSnapshot): Pass them through. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskSnapshot): Use new monitor command arguments. * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateDiskActive) (qemuDomainSnapshotCreateSingleDiskActive): Adjust callers. (qemuDomainSnapshotDiskPrepare): Allow qed, modify rules on reuse.
-
由 Eric Blake 提交于
QEmu 1.1 is adding a 'transaction' command to the JSON monitor. Each element of a transaction corresponds to a top-level command, with the additional guarantee that the transaction flushes all pending I/O, then guarantees that all actions will be successful as a group or that failure will roll back the state to what it was before the monitor command. The difference between a top-level command: { "execute": "blockdev-snapshot-sync", "arguments": { "device": "virtio0", ... } } and a transaction: { "execute": "transaction", "arguments": { "actions": [ { "type": "blockdev-snapshot-sync", "data": { "device": "virtio0", ... } } ] } } is just a couple of changed key names and nesting the shorter command inside a JSON array to the longer command. This patch just adds the framework; the next patch will actually use a transaction. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONMakeCommand): Move guts... (qemuMonitorJSONMakeCommandRaw): ...into new helper. Add support for array element. (qemuMonitorJSONTransaction): New command. (qemuMonitorJSONDiskSnapshot): Support use in a transaction. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDiskSnapshot): Add argument. (qemuMonitorJSONTransaction): New declaration. * src/qemu/qemu_monitor.h (qemuMonitorTransaction): Likewise. (qemuMonitorDiskSnapshot): Add argument. * src/qemu/qemu_monitor.c (qemuMonitorTransaction): New wrapper. (qemuMonitorDiskSnapshot): Pass argument on. * src/qemu/qemu_driver.c (qemuDomainSnapshotCreateSingleDiskActive): Update caller.
-
- 23 3月, 2012 3 次提交
-
-
由 Osier Yang 提交于
This patch introduces a new event type for the QMP event SUSPEND: VIR_DOMAIN_EVENT_ID_PMSUSPEND The event doesn't take any data, but considering there might be reason for wakeup in future, the callback definition is: typedef void (*virConnectDomainEventSuspendCallback)(virConnectPtr conn, virDomainPtr dom, int reason, void *opaque); "reason" is unused currently, always passes "0".
-
由 Osier Yang 提交于
This patch introduces a new event type for the QMP event WAKEUP: VIR_DOMAIN_EVENT_ID_PMWAKEUP The event doesn't take any data, but considering there might be reason for wakeup in future, the callback definition is: typedef void (*virConnectDomainEventWakeupCallback)(virConnectPtr conn, virDomainPtr dom, int reason, void *opaque); "reason" is unused currently, always passes "0".
-
由 Osier Yang 提交于
This patch introduces a new event type for the QMP event DEVICE_TRAY_MOVED, which occurs when the tray of a removable disk is moved (i.e opened or closed): VIR_DOMAIN_EVENT_ID_TRAY_CHANGE The event's data includes the device alias and the reason for tray status' changing, which indicates why the tray status was changed. Thus the callback definition for the event is: enum { VIR_DOMAIN_EVENT_TRAY_CHANGE_OPEN = 0, VIR_DOMAIN_EVENT_TRAY_CHANGE_CLOSE, \#ifdef VIR_ENUM_SENTINELS VIR_DOMAIN_EVENT_TRAY_CHANGE_LAST \#endif } virDomainEventTrayChangeReason; typedef void (*virConnectDomainEventTrayChangeCallback)(virConnectPtr conn, virDomainPtr dom, const char *devAlias, int reason, void *opaque);
-
- 08 3月, 2012 1 次提交
-
-
由 Eric Blake 提交于
Using 'unsigned long' for memory values is risky on 32-bit platforms, as a PAE guest can have more than 4GiB memory. Our API is (unfortunately) locked at 'unsigned long' and a scale of 1024, but the rest of our system should consistently use 64-bit values, especially since the previous patch centralized overflow checking. * src/conf/domain_conf.h (_virDomainDef): Always use 64-bit values for memory. Change hugepage_backed to a bool. * src/conf/domain_conf.c (virDomainDefParseXML) (virDomainDefCheckABIStability, virDomainDefFormatInternal): Fix clients. * src/vmx/vmx.c (virVMXFormatConfig): Likewise. * src/xenxs/xen_sxpr.c (xenParseSxpr, xenFormatSxpr): Likewise. * src/xenxs/xen_xm.c (xenXMConfigGetULongLong): New function. (xenXMConfigGetULong, xenXMConfigSetInt): Avoid truncation. (xenParseXM, xenFormatXM): Fix clients. * src/phyp/phyp_driver.c (phypBuildLpar): Likewise. * src/openvz/openvz_driver.c (openvzDomainSetMemoryInternal): Likewise. * src/vbox/vbox_tmpl.c (vboxDomainDefineXML): Likewise. * src/qemu/qemu_command.c (qemuBuildCommandLine): Likewise. * src/qemu/qemu_process.c (qemuProcessStart): Likewise. * src/qemu/qemu_monitor.h (qemuMonitorGetBalloonInfo): Likewise. * src/qemu/qemu_monitor_text.h (qemuMonitorTextGetBalloonInfo): Likewise. * src/qemu/qemu_monitor_text.c (qemuMonitorTextGetBalloonInfo): Likewise. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONGetBalloonInfo): Likewise. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONGetBalloonInfo): Likewise. * src/qemu/qemu_driver.c (qemudDomainGetInfo) (qemuDomainGetXMLDesc): Likewise. * src/uml/uml_conf.c (umlBuildCommandLine): Likewise.
-
- 01 3月, 2012 1 次提交
-
-
由 Eric Blake 提交于
This actually wires up the new optional parameter to block_stream: http://wiki.qemu.org/Features/LiveBlockMigration/ImageStreamingAPI The error checking is still sparse, since libvirt must not use qemu-img or header probing on a qcow2 file in use by qemu to check if the backing file name is valid; so for now, libvirt is relying on qemu to diagnose an incorrect backing name. Fixing this will require libvirt to track the entire backing file chain at the time qemu is started and keeps it updated with snapshot and pull operations. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONBlockJob): Add parameter, and update callers. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONBlockJob): Update signature. * src/qemu/qemu_monitor.h (qemuMonitorBlockJob): Likewise. * src/qemu/qemu_driver.c (qemuDomainBlockJobImpl): Update caller. * src/qemu/qemu_monitor.c (qemuMonitorBlockJob): Likewise.
-
- 28 2月, 2012 1 次提交
-
-
由 Josh Durgin 提交于
QMP commands don't need to be escaped since converting them to json also escapes special characters. When a QMP command fails, however, libvirt falls back to HMP commands. These fallback functions (qemuMonitorText*) do their own escaping, and pass the result directly to qemuMonitorHMPCommandWithFd. If the monitor is in json mode, these pre-escaped commands will be escaped again when converted to json, which can result in the wrong arguments being sent. For example, a filename test\file would be sent in json as test\\file. This prevented attaching an image file with a " or \ in its name in qemu 1.0.50, and also broke rbd attachment (which uses backslashes to escape some internal arguments.) Reported-by: NMasuko Tomoya <tomoya.masuko@gmail.com> Signed-off-by: NJosh Durgin <josh.durgin@dreamhost.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 27 2月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
using 'system-wakeup' monitor command. It is supported only in JSON, as we are enabling it if possible. Moreover, this command is available in qemu-1.1+ which definitely has JSON.
-
- 15 2月, 2012 1 次提交
-
-
由 Michal Privoznik 提交于
In the future (my next patch in fact) we may want to make decisions depending on qemu having a monitor command or not. Therefore, we want to set qemuCaps flag instead of querying on the monitor each time we are about to make that decision.
-
- 01 2月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
-
- 27 1月, 2012 1 次提交
-
-
由 Jiri Denemark 提交于
QEMU always sends details about all available block devices as an answer for "info block"/"query-block" command. On the other hand, our qemuMonitorGetBlockInfo was made for a single block devices queries only. Thus, when asking for multiple devices, we asked qemu multiple times to always get the same answer from which different parts were filtered. This patch makes qemuMonitorGetBlockInfo return a hash table of all block devices, which may later be used for getting details about specific devices.
-
- 26 1月, 2012 1 次提交
-
-
由 Daniel P. Berrange 提交于
In preparation for the patch to include Murmurhash3, which introduces a virhashcode.h and virhashcode.c files, rename the existing hash.h and hash.c to virhash.h and virhash.c respectively.
-
- 01 12月, 2011 1 次提交
-
-
由 Lei Li 提交于
Implement the block I/O throttle setting and getting support to qemu driver. Signed-off-by: NLei Li <lilei@linux.vnet.ibm.com> Signed-off-by: NZhi Yong Wu <wuzhy@linux.vnet.ibm.com> Signed-off-by: NEric Blake <eblake@redhat.com>
-
- 29 11月, 2011 1 次提交
-
-
由 Osier Yang 提交于
Implements functions for both HMP and QMP mode. For HMP mode, qemu uses "M" as the units by default, so the passed "sized" is divided by 1024. For QMP mode, qemu uses "Bytes" as the units by default, the passed "sized" is multiplied by 1024. All of the monitor functions return -1 on failure, 0 on success, or -2 if not supported.
-
- 28 10月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
The QEMU monitor command 'add_client' can be used to connect to a VNC or SPICE graphics display. This allows for implementation of the virDomainOpenGraphics API * src/qemu/qemu_driver.c: Implement virDomainOpenGraphics * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h, src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add binding for 'add_client' command
-
- 19 10月, 2011 1 次提交
-
-
由 Guido Günther 提交于
-
- 29 9月, 2011 1 次提交
-
-
由 Michal Privoznik 提交于
If the daemon is restarted so we reconnect to monitor, cdrom media can be ejected. In that case we don't want to show it in domain xml, or require it on migration destination. To check for disk status use 'info block' monitor command.
-
- 28 9月, 2011 1 次提交
-
-
由 Jiri Denemark 提交于
Current qemu is able to give us detailed domain status (not just if it is running or not) which we can translate into a status reason.
-
- 16 9月, 2011 1 次提交
-
-
由 Peter Krempa 提交于
/usr/lib/stdlib.h in Mac OS X and probably also in BSD's exports this symbol :(
-
- 06 9月, 2011 2 次提交
-
-
由 Peter Krempa 提交于
This patch adds handlers for modification of guest's interface link state. Both HMP and QMP commands are supported, but as the link state functionality is from the beginning supported in QMP the HMP code will probably never be used.
-
由 Osier Yang 提交于
The mainly changes are: 1) Update qemuMonitorGetBlockStatsInfo and it's children (Text/JSON) functions to return the value of new latency fields. 2) Add new function qemuMonitorGetBlockStatsParamsNumber, which is to count how many parameters the underlying QEMU supports. 3) Update virDomainBlockStats in src/qemu/qemu_driver.c to be compatible with the changes by 1).
-
- 05 9月, 2011 1 次提交
-
-
由 Eric Blake 提交于
No one uses this yet, but it will be important once virDomainSnapshotCreateXML learns a VIR_DOMAIN_SNAPSHOT_DISK_ONLY flag, and the xml allows passing in the new file names. * src/qemu/qemu_monitor.h (qemuMonitorDiskSnapshot): New prototype. * src/qemu/qemu_monitor_text.h (qemuMonitorTextDiskSnapshot): Likewise. * src/qemu/qemu_monitor_json.h (qemuMonitorJSONDiskSnapshot): Likewise. * src/qemu/qemu_monitor.c (qemuMonitorDiskSnapshot): New function. * src/qemu/qemu_monitor_json.c (qemuMonitorJSONDiskSnapshot): Likewise.
-
- 22 7月, 2011 2 次提交
-
-
由 Adam Litke 提交于
When an operation started by virDomainBlockPull completes (either with success or with failure), raise an event to indicate the final status. This API allow users to avoid polling on virDomainGetBlockJobInfo if they would prefer to use an event mechanism. * daemon/remote.c: Dispatch events to client * include/libvirt/libvirt.h.in: Define event ID and callback signature * src/conf/domain_event.c, src/conf/domain_event.h, src/libvirt_private.syms: Extend API to handle the new event * src/qemu/qemu_driver.c: Connect to the QEMU monitor event for block_stream completion and emit a libvirt block pull event * src/remote/remote_driver.c: Receive and dispatch events to application * src/remote/remote_protocol.x: Wire protocol definition for the event * src/remote_protocol-structs: structure definitions for protocol verification * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c: Watch for BLOCK_STREAM_COMPLETED event from QEMU monitor
-
由 Adam Litke 提交于
The virDomainBlockPull* family of commands are enabled by the following HMP/QMP commands: 'block_stream', 'block_job_cancel', 'info block-jobs' / 'query-block-jobs', and 'block_job_set_speed'. * src/qemu/qemu_driver.c src/qemu/qemu_monitor_text.[ch]: implement disk streaming by using the proper qemu monitor commands. * src/qemu/qemu_monitor_json.[ch]: implement commands using the qmp monitor
-
- 21 7月, 2011 1 次提交
-
-
由 Lai Jiangshan 提交于
qemu driver just accept xt_kbd codeset's keycode, so the lib virtkey is used for translating keycodes from other codesets
-
- 14 7月, 2011 1 次提交
-
-
由 Jiri Denemark 提交于
When qemuMonitorCloseFileHandle is called in error path, we need to preserve the original error since a possible further error when running closefd monitor command is not very useful to users.
-
- 12 7月, 2011 1 次提交
-
-
由 Daniel P. Berrange 提交于
When attaching to an external QEMU process, it is neccessary to check if the process is using KVM or not. This can be done using a monitor command * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h, src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add API for checking if KVM is enabled
-
- 24 6月, 2011 3 次提交
-
-
由 Eric Blake 提交于
This reverts commit 784ee08d.
-
由 Eric Blake 提交于
This reverts commit 12cd77a0. Conflicts: python/libvirt-override-virConnect.py python/libvirt-override.c src/remote/remote_protocol.x
-
由 Daniel P. Berrange 提交于
For controlled shutdown we issue a 'system_powerdown' command to the QEMU monitor. This triggers an ACPI event which (most) guest OS wire up to a controlled shutdown. There is no equiv ACPI event to trigger a controlled reboot. This patch attempts to fake a reboot. - In qemuDomainObjPrivatePtr we have a bool fakeReboot flag. - The virDomainReboot method sets this flag and then triggers a normal 'system_powerdown'. - The QEMU process is started with '-no-shutdown' so that the guest CPUs pause when it powers off the guest - When we receive the 'POWEROFF' event from QEMU JSON monitor if fakeReboot is not set we invoke the qemuProcessKill command and shutdown continues normally - If fakeReboot was set, we spawn a background thread which issues 'system_reset' to perform a warm reboot of the guest hardware. Then it issues 'cont' to start the CPUs again * src/qemu/qemu_command.c: Add -no-shutdown flag if we have JSON support * src/qemu/qemu_domain.h: Add 'fakeReboot' flag to qemuDomainObjPrivate struct * src/qemu/qemu_driver.c: Fake reboot using the system_powerdown command if JSON support is available * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h, src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add binding for system_reset command * src/qemu/qemu_process.c: Reset the guest & start CPUs if fakeReboot is set
-
- 15 6月, 2011 2 次提交
-
-
由 Adam Litke 提交于
When an operation started by virDomainBlockPullAll completes (either with success or with failure), raise an event to indicate the final status. This allows an API user to avoid polling on virDomainBlockPullInfo if they would prefer to use the event mechanism. * daemon/remote.c: Dispatch events to client * include/libvirt/libvirt.h.in: Define event ID and callback signature * src/conf/domain_event.c, src/conf/domain_event.h, src/libvirt_private.syms: Extend API to handle the new event * src/qemu/qemu_driver.c: Connect to the QEMU monitor event for block_stream completion and emit a libvirt block pull event * src/remote/remote_driver.c: Receive and dispatch events to application * src/remote/remote_protocol.x: Wire protocol definition for the event * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c: Watch for BLOCK_STREAM_COMPLETED event from QEMU monitor Signed-off-by: NAdam Litke <agl@us.ibm.com>
-
由 Adam Litke 提交于
The virDomainBlockPull* family of commands are enabled by the 'block_stream' and 'info block_stream' qemu monitor commands. * src/qemu/qemu_driver.c src/qemu/qemu_monitor_text.[ch]: implement disk streaming by using the stream and info stream text monitor commands * src/qemu/qemu_monitor_json.[ch]: implement commands using the qmp monitor Signed-off-by: NAdam Litke <agl@us.ibm.com> Acked-by: NDaniel P. Berrange <berrange@redhat.com>
-
- 29 5月, 2011 2 次提交
-
-
由 Daniel P. Berrange 提交于
Currently the QEMU monitor I/O handler code uses errno values to report errors. This results in a sub-optimal error messages on certain conditions, in particular when parsing JSON strings malformed data simply results in 'EINVAL'. This changes the code to use the standard libvirt error reporting APIs. The virError is stored against the qemuMonitorPtr struct, and when a monitor API is run, any existing stored error is copied into that thread's error local * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_text.c: Use virError APIs for all monitor I/O handling code
-
由 Daniel P. Berrange 提交于
Currently whenever there is any failure with parsing the monitor, this is treated in the same was as end-of-file (ie QEMU quit). The domain is terminated, if not already dead. With this change, failures in parsing the monitor stream do not result in the death of QEMU. The guest continues running unchanged, but all further use of the monitor will be disabled. The VMM_FAILURE event will be emitted, and the mgmt application can decide when to kill/restart the guest to re-gain control * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h: Run a different callback for monitor EOF vs error conditions. * src/qemu/qemu_process.c: Emit VMM_FAILURE event when monitor fails
-
- 16 5月, 2011 2 次提交
-
-
由 Daniel P. Berrange 提交于
Use the graphics information from the QEMU migration cookie to issue a 'client_migrate_info' monitor command to QEMU. This causes the SPICE client to automatically reconnect to the target host when migration completes * src/qemu/qemu_migration.c: Set data for SPICE client relocation before starting migration on src * src/qemu/qemu_monitor.c, src/qemu/qemu_monitor.h, src/qemu/qemu_monitor_json.c, src/qemu/qemu_monitor_json.h, src/qemu/qemu_monitor_text.c, src/qemu/qemu_monitor_text.h: Add new qemuMonitorGraphicsRelocate() command
-
由 Jiri Denemark 提交于
A qemu domain can get paused when libvirtd is stopped (e.g., because of I/O error) so we should check its current state when reconnecting to it.
-