2009-06-06 08:22:04 +00:00
|
|
|
HXCOMM Use DEFHEADING() to define headings in both help text and texi
|
|
|
|
HXCOMM Text between STEXI and ETEXI are copied to texi version and
|
|
|
|
HXCOMM discarded from C version
|
|
|
|
HXCOMM DEF(command, args, callback, arg_string, help) is used to construct
|
|
|
|
HXCOMM monitor commands
|
|
|
|
HXCOMM HXCOMM can be used for comments, discarded from both texi and C
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@table @option
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "help|?",
|
2013-08-27 12:38:26 +00:00
|
|
|
.args_type = "name:S?",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "[cmd]",
|
|
|
|
.help = "show the help",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = do_help_cmd,
|
2018-06-20 15:39:42 +00:00
|
|
|
.flags = "p",
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item help or ? [@var{cmd}]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex help
|
2009-06-06 08:22:04 +00:00
|
|
|
Show the help for all commands or just for command @var{cmd}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "commit",
|
|
|
|
.args_type = "device:B",
|
|
|
|
.params = "device|all",
|
|
|
|
.help = "commit changes to the disk images (if -snapshot is used) or backing files",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_commit,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item commit
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex commit
|
2009-06-06 08:22:04 +00:00
|
|
|
Commit changes to the disk images (if -snapshot is used) or backing files.
|
2014-01-24 14:02:37 +00:00
|
|
|
If the backing file is smaller than the snapshot, then the backing file will be
|
|
|
|
resized to be the same size as the snapshot. If the snapshot is smaller than
|
|
|
|
the backing file, the backing file will not be truncated. If you want the
|
|
|
|
backing file to match the size of the smaller snapshot, you can safely truncate
|
|
|
|
it yourself once the commit operation successfully completes.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "q|quit",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "quit the emulator",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_quit,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item q or quit
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex quit
|
2009-06-06 08:22:04 +00:00
|
|
|
Quit the emulator.
|
2018-06-20 15:39:46 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "exit_preconfig",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "exit the preconfig state",
|
|
|
|
.cmd = hmp_exit_preconfig,
|
|
|
|
.flags = "p",
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item exit_preconfig
|
|
|
|
@findex exit_preconfig
|
|
|
|
This command makes QEMU exit the preconfig state and proceed with
|
|
|
|
VM initialization using configuration data provided on the command line
|
|
|
|
and via the QMP monitor during the preconfig state. The command is only
|
|
|
|
available during the preconfig state (i.e. when the --preconfig command
|
|
|
|
line option was in use).
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2011-01-24 12:32:33 +00:00
|
|
|
{
|
|
|
|
.name = "block_resize",
|
|
|
|
.args_type = "device:B,size:o",
|
|
|
|
.params = "device size",
|
|
|
|
.help = "resize a block image",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_resize,
|
2011-01-24 12:32:33 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_resize
|
|
|
|
@findex block_resize
|
|
|
|
Resize a block image while a guest is running. Usually requires guest
|
|
|
|
action to see the updated size. Resize to a lower size is supported,
|
|
|
|
but should be used with extreme caution. Note that this command only
|
|
|
|
resizes image files, it can not resize block devices like LVM volumes.
|
|
|
|
ETEXI
|
|
|
|
|
2012-01-18 14:40:46 +00:00
|
|
|
{
|
|
|
|
.name = "block_stream",
|
2012-04-25 15:51:03 +00:00
|
|
|
.args_type = "device:B,speed:o?,base:s?",
|
|
|
|
.params = "device [speed [base]]",
|
2012-01-18 14:40:46 +00:00
|
|
|
.help = "copy data from a backing file into a block device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_stream,
|
2012-01-18 14:40:46 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_stream
|
|
|
|
@findex block_stream
|
|
|
|
Copy data from a backing file into a block device.
|
2012-01-18 14:40:47 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_job_set_speed",
|
2012-04-25 15:51:02 +00:00
|
|
|
.args_type = "device:B,speed:o",
|
|
|
|
.params = "device speed",
|
2012-01-18 14:40:47 +00:00
|
|
|
.help = "set maximum speed for a background block operation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_job_set_speed,
|
2012-01-18 14:40:47 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
2012-04-13 10:03:46 +00:00
|
|
|
@item block_job_set_speed
|
|
|
|
@findex block_job_set_speed
|
2012-01-18 14:40:47 +00:00
|
|
|
Set maximum speed for a background block operation.
|
2012-01-18 14:40:48 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_job_cancel",
|
2012-09-28 15:22:51 +00:00
|
|
|
.args_type = "force:-f,device:B",
|
|
|
|
.params = "[-f] device",
|
|
|
|
.help = "stop an active background block operation (use -f"
|
block/mirror: change the semantic of 'force' of block-job-cancel
When doing drive mirror to a low speed shared storage, if there was heavy
BLK IO write workload in VM after the 'ready' event, drive mirror block job
can't be canceled immediately, it would keep running until the heavy BLK IO
workload stopped in the VM.
Libvirt depends on the current block-job-cancel semantics, which is that
when used without a flag after the 'ready' event, the command blocks
until data is in sync. However, these semantics are awkward in other
situations, for example, people may use drive mirror for realtime
backups while still wanting to use block live migration. Libvirt cannot
start a block live migration while another drive mirror is in progress,
but the user would rather abandon the backup attempt as broken and
proceed with the live migration than be stuck waiting for the current
drive mirror backup to finish.
The drive-mirror command already includes a 'force' flag, which libvirt
does not use, although it documented the flag as only being useful to
quit a job which is paused. However, since quitting a paused job has
the same effect as abandoning a backup in a non-paused job (namely, the
destination file is not in sync, and the command completes immediately),
we can just improve the documentation to make the force flag obviously
useful.
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Jeff Cody <jcody@redhat.com>
Cc: Kevin Wolf <kwolf@redhat.com>
Cc: Max Reitz <mreitz@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: John Snow <jsnow@redhat.com>
Reported-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Huaitong Han <huanhuaitong@didichuxing.com>
Signed-off-by: Liang Li <liliangleo@didichuxing.com>
Signed-off-by: Jeff Cody <jcody@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-03-13 12:12:16 +00:00
|
|
|
"\n\t\t\t if you want to abort the operation immediately"
|
|
|
|
"\n\t\t\t instead of keep running until data is in sync)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_job_cancel,
|
2012-01-18 14:40:48 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_job_cancel
|
|
|
|
@findex block_job_cancel
|
2012-10-18 14:49:21 +00:00
|
|
|
Stop an active background block operation (streaming, mirroring).
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_job_complete",
|
|
|
|
.args_type = "device:B",
|
|
|
|
.params = "device",
|
|
|
|
.help = "stop an active background block operation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_job_complete,
|
2012-10-18 14:49:21 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_job_complete
|
|
|
|
@findex block_job_complete
|
|
|
|
Manually trigger completion of an active background block operation.
|
|
|
|
For mirroring, this will switch the device to the destination path.
|
2012-09-28 15:22:51 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_job_pause",
|
|
|
|
.args_type = "device:B",
|
|
|
|
.params = "device",
|
|
|
|
.help = "pause an active background block operation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_job_pause,
|
2012-09-28 15:22:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_job_pause
|
|
|
|
@findex block_job_pause
|
|
|
|
Pause an active block streaming operation.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_job_resume",
|
|
|
|
.args_type = "device:B",
|
|
|
|
.params = "device",
|
|
|
|
.help = "resume a paused background block operation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_job_resume,
|
2012-09-28 15:22:51 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item block_job_resume
|
|
|
|
@findex block_job_resume
|
|
|
|
Resume a paused block streaming operation.
|
2012-01-18 14:40:46 +00:00
|
|
|
ETEXI
|
2011-01-24 12:32:33 +00:00
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "eject",
|
2009-12-14 20:53:21 +00:00
|
|
|
.args_type = "force:-f,device:B",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "[-f] device",
|
|
|
|
.help = "eject a removable medium (use -f to force it)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_eject,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item eject [-f] @var{device}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex eject
|
2009-06-06 08:22:04 +00:00
|
|
|
Eject a removable medium (use -f to force it).
|
2010-11-12 17:07:13 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "drive_del",
|
2014-04-13 15:25:05 +00:00
|
|
|
.args_type = "id:B",
|
2010-11-12 17:07:13 +00:00
|
|
|
.params = "device",
|
|
|
|
.help = "remove host block device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_drive_del,
|
2010-11-12 17:07:13 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item drive_del @var{device}
|
|
|
|
@findex drive_del
|
|
|
|
Remove host block device. The result is that guest generated IO is no longer
|
|
|
|
submitted against the host device underlying the disk. Once a drive has
|
|
|
|
been deleted, the QEMU Block layer returns -EIO which results in IO
|
|
|
|
errors in the guest for applications that are reading/writing to the device.
|
2013-06-05 08:33:14 +00:00
|
|
|
These errors are always reported to the guest, regardless of the drive's error
|
|
|
|
actions (drive options rerror, werror).
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "change",
|
2015-10-26 20:39:18 +00:00
|
|
|
.args_type = "device:B,target:F,arg:s?,read-only-mode:s?",
|
|
|
|
.params = "device filename [format [read-only-mode]]",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "change a removable medium, optional format",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_change,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item change @var{device} @var{setting}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex change
|
2009-06-06 08:22:04 +00:00
|
|
|
Change the configuration of a device.
|
|
|
|
|
|
|
|
@table @option
|
2015-10-26 20:39:18 +00:00
|
|
|
@item change @var{diskdevice} @var{filename} [@var{format} [@var{read-only-mode}]]
|
2009-06-06 08:22:04 +00:00
|
|
|
Change the medium for a removable disk device to point to @var{filename}. eg
|
|
|
|
|
|
|
|
@example
|
|
|
|
(qemu) change ide1-cd0 /path/to/some.iso
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@var{format} is optional.
|
|
|
|
|
2015-10-26 20:39:18 +00:00
|
|
|
@var{read-only-mode} may be used to change the read-only status of the device.
|
|
|
|
It accepts the following values:
|
|
|
|
|
|
|
|
@table @var
|
|
|
|
@item retain
|
|
|
|
Retains the current status; this is the default.
|
|
|
|
|
|
|
|
@item read-only
|
|
|
|
Makes the device read-only.
|
|
|
|
|
|
|
|
@item read-write
|
|
|
|
Makes the device writable.
|
|
|
|
@end table
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
@item change vnc @var{display},@var{options}
|
|
|
|
Change the configuration of the VNC server. The valid syntax for @var{display}
|
|
|
|
and @var{options} are described at @ref{sec_invocation}. eg
|
|
|
|
|
|
|
|
@example
|
|
|
|
(qemu) change vnc localhost:1
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@item change vnc password [@var{password}]
|
|
|
|
|
|
|
|
Change the password associated with the VNC server. If the new password is not
|
|
|
|
supplied, the monitor will prompt for it to be entered. VNC passwords are only
|
|
|
|
significant up to 8 letters. eg
|
|
|
|
|
|
|
|
@example
|
|
|
|
(qemu) change vnc password
|
|
|
|
Password: ********
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@end table
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "screendump",
|
2018-03-05 16:37:48 +00:00
|
|
|
.args_type = "filename:F,device:s?,head:i?",
|
|
|
|
.params = "filename [device [head]]",
|
|
|
|
.help = "save screen from head 'head' of display device 'device' "
|
|
|
|
"into PPM image 'filename'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_screendump,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item screendump @var{filename}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex screendump
|
2009-06-06 08:22:04 +00:00
|
|
|
Save screen into PPM image @var{filename}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "logfile",
|
|
|
|
.args_type = "filename:F",
|
|
|
|
.params = "filename",
|
|
|
|
.help = "output logs to 'filename'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_logfile,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item logfile @var{filename}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex logfile
|
2009-06-06 08:22:04 +00:00
|
|
|
Output logs to @var{filename}.
|
|
|
|
ETEXI
|
|
|
|
|
2010-06-24 11:34:53 +00:00
|
|
|
{
|
|
|
|
.name = "trace-event",
|
2016-07-11 10:53:57 +00:00
|
|
|
.args_type = "name:s,option:b,vcpu:i?",
|
|
|
|
.params = "name on|off [vcpu]",
|
|
|
|
.help = "changes status of a specific trace event "
|
|
|
|
"(vcpu: vCPU to set, default is all)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_trace_event,
|
2015-08-14 10:27:43 +00:00
|
|
|
.command_completion = trace_event_completion,
|
2010-06-24 11:34:53 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item trace-event
|
|
|
|
@findex trace-event
|
|
|
|
changes status of a trace event
|
2010-07-13 08:26:33 +00:00
|
|
|
ETEXI
|
|
|
|
|
2011-10-02 13:44:37 +00:00
|
|
|
#if defined(CONFIG_TRACE_SIMPLE)
|
2010-07-13 08:26:33 +00:00
|
|
|
{
|
|
|
|
.name = "trace-file",
|
|
|
|
.args_type = "op:s?,arg:F?",
|
|
|
|
.params = "on|off|flush|set [arg]",
|
|
|
|
.help = "open, close, or flush trace file, or set a new file name",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_trace_file,
|
2010-07-13 08:26:33 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item trace-file on|off|flush
|
|
|
|
@findex trace-file
|
|
|
|
Open, close, or flush the trace file. If no argument is given, the status of the trace file is displayed.
|
2010-06-24 11:34:53 +00:00
|
|
|
ETEXI
|
|
|
|
#endif
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "log",
|
|
|
|
.args_type = "items:s",
|
|
|
|
.params = "item1[,...]",
|
2013-02-26 17:52:40 +00:00
|
|
|
.help = "activate logging of the specified items",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_log,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item log @var{item1}[,...]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex log
|
2013-02-26 17:52:40 +00:00
|
|
|
Activate logging of the specified items.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "savevm",
|
|
|
|
.args_type = "name:s?",
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
.params = "tag",
|
|
|
|
.help = "save a VM snapshot. If no tag is provided, a new snapshot is created",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_savevm,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
@item savevm @var{tag}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex savevm
|
2009-06-06 08:22:04 +00:00
|
|
|
Create a snapshot of the whole virtual machine. If @var{tag} is
|
|
|
|
provided, it is used as human readable identifier. If there is already
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
a snapshot with the same tag, it is replaced. More info at
|
2009-06-06 08:22:04 +00:00
|
|
|
@ref{vm_snapshots}.
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
|
|
|
|
Since 4.0, savevm stopped allowing the snapshot id to be set, accepting
|
|
|
|
only @var{tag} as parameter.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "loadvm",
|
|
|
|
.args_type = "name:s",
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
.params = "tag",
|
|
|
|
.help = "restore a VM snapshot from its tag",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_loadvm,
|
2014-05-27 22:39:37 +00:00
|
|
|
.command_completion = loadvm_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
@item loadvm @var{tag}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex loadvm
|
2009-06-06 08:22:04 +00:00
|
|
|
Set the whole virtual machine to the snapshot identified by the tag
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
@var{tag}.
|
|
|
|
|
|
|
|
Since 4.0, loadvm stopped accepting snapshot id as parameter.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "delvm",
|
|
|
|
.args_type = "name:s",
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
.params = "tag",
|
|
|
|
.help = "delete a VM snapshot from its tag",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_delvm,
|
2014-05-27 22:39:37 +00:00
|
|
|
.command_completion = delvm_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
@item delvm @var{tag}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex delvm
|
block/snapshot.c: eliminate use of ID input in snapshot operations
At this moment, QEMU attempts to create/load/delete snapshots
by using either an ID (id_str) or a name. The problem is that the code
isn't consistent of whether the entered argument is an ID or a name,
causing unexpected behaviors.
For example, when creating snapshots via savevm <arg>, what happens is that
"arg" is treated as both name and id_str. In a guest without snapshots, create
a single snapshot via savevm:
(qemu) savevm 0
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 0 741M 2018-07-31 13:39:56 00:41:25.313
A snapshot with name "0" is created. ID is hidden from the user, but the
ID is a non-zero integer that starts at "1". Thus, this snapshot has
id_str=1, TAG="0". Creating a second snapshot with arg = 1, the first one
is deleted:
(qemu) savevm 1
(qemu) info snapshots
List of snapshots present on all disks:
ID TAG VM SIZE DATE VM CLOCK
-- 1 741M 2018-07-31 13:42:14 00:41:55.252
What happened?
- when creating the second snapshot, a verification is done inside
bdrv_all_delete_snapshot to delete any existing snapshots that matches an
string argument. Here, the code calls bdrv_all_delete_snapshot("1", ...);
- bdrv_all_delete_snapshot calls bdrv_snapshot_find(..., "1") for each
BlockDriverState of the guest. And this is where things goes tilting:
bdrv_snapshot_find does a search by both id_str and name. It finds
out that there is a snapshot that has id_str = 1, stores a reference
to the snapshot in the sn_info pointer and then returns match found;
- since a match was found, a call to bdrv_snapshot_delete_by_id_or_name() is
made. This function ignores the pointer written by bdrv_snapshot_find. Instead,
it deletes the snapshot using bdrv_snapshot_delete() calling it first with
id_str = 1. If it fails to delete, then it calls it again with name = 1.
- after all that, QEMU creates the new snapshot, that has id_str = 1 and
name = 1. The user is left wondering that happened with the first snapshot
created. Similar bugs can be triggered when using loadvm and delvm.
Before contemplating discarding the use of ID input in these operations,
I've searched the code of what would be the implications. My findings
are:
- the RBD and Sheepdog drivers don't care. Both uses the 'name' field as
key in their logic, making id_str = name when appropriate.
replay-snapshot.c does not make any special use of id_str;
- qcow2 uses id_str as an unique identifier but it is automatically
calculated, not being influenced by user input. Other than that, there are
no distinguish operations made only with id_str;
- in blockdev.c, the delete operation uses a match of both id_str AND
name. Given that id_str is either a copy of 'name' or auto-generated,
we're fine here.
This gives motivation to not consider ID as a valid user input in HMP
commands - sticking with 'name' input only is more consistent. To
accomplish that, the following changes were made in this patch:
- bdrv_snapshot_find() does not match for id_str anymore, only 'name'. The
function is called in save_snapshot(), load_snapshot(), bdrv_all_delete_snapshot()
and bdrv_all_find_snapshot(). This change makes the search function more
predictable and does not change the behavior of any underlying code that uses
these affected functions, which are related to HMP (which is fine) and the
main loop inside vl.c (which doesn't care about it anyways);
- bdrv_all_delete_snapshot() does not call bdrv_snapshot_delete_by_id_or_name
anymore. Instead, it uses the pointer returned by bdrv_snapshot_find to
erase the snapshot with the exact match of id_str an name. This function
is called in save_snapshot and hmp_delvm, thus this change produces the
intended effect;
- documentation changes to reflect the new behavior. I consider this to
be an API fix instead of an API change - the user was already creating
snapshots using 'name', but now he/she will also enjoy a consistent
behavior.
Ideally we would get rid of the id_str field entirely, but this would have
repercussions on existing snapshots. Another day perhaps.
Signed-off-by: Daniel Henrique Barboza <danielhb413@gmail.com>
Acked-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Signed-off-by: Kevin Wolf <kwolf@redhat.com>
2018-11-07 13:09:58 +00:00
|
|
|
Delete the snapshot identified by @var{tag}.
|
|
|
|
|
|
|
|
Since 4.0, delvm stopped deleting snapshots by snapshot id, accepting
|
|
|
|
only @var{tag} as parameter.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "singlestep",
|
|
|
|
.args_type = "option:s?",
|
|
|
|
.params = "[on|off]",
|
|
|
|
.help = "run emulation in singlestep mode or switch to normal mode",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_singlestep,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item singlestep [off]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex singlestep
|
2009-06-06 08:22:04 +00:00
|
|
|
Run the emulation in single step mode.
|
|
|
|
If called with option off, the emulation returns to normal mode.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "stop",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "stop emulation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_stop,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item stop
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex stop
|
2009-06-06 08:22:04 +00:00
|
|
|
Stop emulation.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "c|cont",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "resume emulation",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_cont,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item c or cont
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex cont
|
2009-06-06 08:22:04 +00:00
|
|
|
Resume emulation.
|
2012-02-23 12:45:21 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "system_wakeup",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "wakeup guest from suspend",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_system_wakeup,
|
2012-02-23 12:45:21 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item system_wakeup
|
|
|
|
@findex system_wakeup
|
|
|
|
Wakeup guest from suspend.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "gdbserver",
|
|
|
|
.args_type = "device:s?",
|
|
|
|
.params = "[device]",
|
|
|
|
.help = "start gdbserver on given device (default 'tcp::1234'), stop with 'none'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_gdbserver,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item gdbserver [@var{port}]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex gdbserver
|
2009-06-06 08:22:04 +00:00
|
|
|
Start gdbserver session (default @var{port}=1234)
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "x",
|
|
|
|
.args_type = "fmt:/,addr:l",
|
|
|
|
.params = "/fmt addr",
|
|
|
|
.help = "virtual memory dump starting at 'addr'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_memory_dump,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item x/fmt @var{addr}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex x
|
2009-06-06 08:22:04 +00:00
|
|
|
Virtual memory dump starting at @var{addr}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "xp",
|
|
|
|
.args_type = "fmt:/,addr:l",
|
|
|
|
.params = "/fmt addr",
|
|
|
|
.help = "physical memory dump starting at 'addr'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_physical_memory_dump,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item xp /@var{fmt} @var{addr}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex xp
|
2009-06-06 08:22:04 +00:00
|
|
|
Physical memory dump starting at @var{addr}.
|
|
|
|
|
|
|
|
@var{fmt} is a format which tells the command how to format the
|
|
|
|
data. Its syntax is: @option{/@{count@}@{format@}@{size@}}
|
|
|
|
|
|
|
|
@table @var
|
|
|
|
@item count
|
|
|
|
is the number of items to be dumped.
|
|
|
|
|
|
|
|
@item format
|
|
|
|
can be x (hex), d (signed decimal), u (unsigned decimal), o (octal),
|
|
|
|
c (char) or i (asm instruction).
|
|
|
|
|
|
|
|
@item size
|
|
|
|
can be b (8 bits), h (16 bits), w (32 bits) or g (64 bits). On x86,
|
|
|
|
@code{h} or @code{w} can be specified with the @code{i} format to
|
|
|
|
respectively select 16 or 32 bit code instruction size.
|
|
|
|
|
|
|
|
@end table
|
|
|
|
|
|
|
|
Examples:
|
|
|
|
@itemize
|
|
|
|
@item
|
|
|
|
Dump 10 instructions at the current instruction pointer:
|
|
|
|
@example
|
|
|
|
(qemu) x/10i $eip
|
|
|
|
0x90107063: ret
|
|
|
|
0x90107064: sti
|
|
|
|
0x90107065: lea 0x0(%esi,1),%esi
|
|
|
|
0x90107069: lea 0x0(%edi,1),%edi
|
|
|
|
0x90107070: ret
|
|
|
|
0x90107071: jmp 0x90107080
|
|
|
|
0x90107073: nop
|
|
|
|
0x90107074: nop
|
|
|
|
0x90107075: nop
|
|
|
|
0x90107076: nop
|
|
|
|
@end example
|
|
|
|
|
|
|
|
@item
|
|
|
|
Dump 80 16 bit values at the start of the video memory.
|
|
|
|
@smallexample
|
|
|
|
(qemu) xp/80hx 0xb8000
|
|
|
|
0x000b8000: 0x0b50 0x0b6c 0x0b65 0x0b78 0x0b38 0x0b36 0x0b2f 0x0b42
|
|
|
|
0x000b8010: 0x0b6f 0x0b63 0x0b68 0x0b73 0x0b20 0x0b56 0x0b47 0x0b41
|
|
|
|
0x000b8020: 0x0b42 0x0b69 0x0b6f 0x0b73 0x0b20 0x0b63 0x0b75 0x0b72
|
|
|
|
0x000b8030: 0x0b72 0x0b65 0x0b6e 0x0b74 0x0b2d 0x0b63 0x0b76 0x0b73
|
|
|
|
0x000b8040: 0x0b20 0x0b30 0x0b35 0x0b20 0x0b4e 0x0b6f 0x0b76 0x0b20
|
|
|
|
0x000b8050: 0x0b32 0x0b30 0x0b30 0x0b33 0x0720 0x0720 0x0720 0x0720
|
|
|
|
0x000b8060: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
|
|
|
|
0x000b8070: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
|
|
|
|
0x000b8080: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
|
|
|
|
0x000b8090: 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720 0x0720
|
|
|
|
@end smallexample
|
|
|
|
@end itemize
|
2017-04-20 13:30:58 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "gpa2hva",
|
|
|
|
.args_type = "addr:l",
|
|
|
|
.params = "addr",
|
|
|
|
.help = "print the host virtual address corresponding to a guest physical address",
|
|
|
|
.cmd = hmp_gpa2hva,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item gpa2hva @var{addr}
|
|
|
|
@findex gpa2hva
|
|
|
|
Print the host virtual address at which the guest's physical address @var{addr}
|
|
|
|
is mapped.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
#ifdef CONFIG_LINUX
|
|
|
|
{
|
|
|
|
.name = "gpa2hpa",
|
|
|
|
.args_type = "addr:l",
|
|
|
|
.params = "addr",
|
|
|
|
.help = "print the host physical address corresponding to a guest physical address",
|
|
|
|
.cmd = hmp_gpa2hpa,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item gpa2hpa @var{addr}
|
|
|
|
@findex gpa2hpa
|
|
|
|
Print the host physical address at which the guest's physical address @var{addr}
|
|
|
|
is mapped.
|
2019-04-12 15:26:52 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "gva2gpa",
|
|
|
|
.args_type = "addr:l",
|
|
|
|
.params = "addr",
|
|
|
|
.help = "print the guest physical address corresponding to a guest virtual address",
|
|
|
|
.cmd = hmp_gva2gpa,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item gva2gpa @var{addr}
|
|
|
|
@findex gva2gpa
|
|
|
|
Print the guest physical address at which the guest's virtual address @var{addr}
|
|
|
|
is mapped based on the mapping for the current CPU.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "p|print",
|
|
|
|
.args_type = "fmt:/,val:l",
|
|
|
|
.params = "/fmt expr",
|
|
|
|
.help = "print expression value (use $reg for CPU register access)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = do_print,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item p or print/@var{fmt} @var{expr}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex print
|
2009-06-06 08:22:04 +00:00
|
|
|
Print expression value. Only the @var{format} part of @var{fmt} is
|
|
|
|
used.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "i",
|
|
|
|
.args_type = "fmt:/,addr:i,index:i.",
|
|
|
|
.params = "/fmt addr",
|
|
|
|
.help = "I/O port read",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_ioport_read,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item i/@var{fmt} @var{addr} [.@var{index}]
|
|
|
|
@findex i
|
2009-06-06 08:22:04 +00:00
|
|
|
Read I/O port.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "o",
|
|
|
|
.args_type = "fmt:/,addr:i,val:i",
|
|
|
|
.params = "/fmt addr value",
|
|
|
|
.help = "I/O port write",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_ioport_write,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-07-14 08:20:11 +00:00
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item o/@var{fmt} @var{addr} @var{val}
|
|
|
|
@findex o
|
2009-07-14 08:20:11 +00:00
|
|
|
Write to I/O port.
|
|
|
|
ETEXI
|
2009-06-06 08:22:04 +00:00
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "sendkey",
|
2012-08-31 02:56:22 +00:00
|
|
|
.args_type = "keys:s,hold-time:i?",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "keys [hold_ms]",
|
|
|
|
.help = "send keys to the VM (e.g. 'sendkey ctrl-alt-f1', default hold time=100 ms)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_sendkey,
|
2014-05-07 22:41:27 +00:00
|
|
|
.command_completion = sendkey_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item sendkey @var{keys}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex sendkey
|
2012-08-31 02:56:20 +00:00
|
|
|
Send @var{keys} to the guest. @var{keys} could be the name of the
|
|
|
|
key or the raw value in hexadecimal format. Use @code{-} to press
|
|
|
|
several keys simultaneously. Example:
|
2009-06-06 08:22:04 +00:00
|
|
|
@example
|
|
|
|
sendkey ctrl-alt-f1
|
|
|
|
@end example
|
|
|
|
|
|
|
|
This command is useful to send keys that your graphical user interface
|
|
|
|
intercepts at low level, such as @code{ctrl-alt-f1} in X Window.
|
2018-08-15 20:00:03 +00:00
|
|
|
ETEXI
|
|
|
|
{
|
|
|
|
.name = "sync-profile",
|
|
|
|
.args_type = "op:s?",
|
|
|
|
.params = "[on|off|reset]",
|
|
|
|
.help = "enable, disable or reset synchronization profiling. "
|
|
|
|
"With no arguments, prints whether profiling is on or off.",
|
|
|
|
.cmd = hmp_sync_profile,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item sync-profile [on|off|reset]
|
|
|
|
@findex sync-profile
|
|
|
|
Enable, disable or reset synchronization profiling. With no arguments, prints
|
|
|
|
whether profiling is on or off.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "system_reset",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "reset the system",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_system_reset,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item system_reset
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex system_reset
|
2009-06-06 08:22:04 +00:00
|
|
|
Reset the system.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "system_powerdown",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "send system power down event",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_system_powerdown,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item system_powerdown
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex system_powerdown
|
2009-06-06 08:22:04 +00:00
|
|
|
Power down the system (if supported).
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "sum",
|
|
|
|
.args_type = "start:i,size:i",
|
|
|
|
.params = "addr size",
|
|
|
|
.help = "compute the checksum of a memory region",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_sum,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item sum @var{addr} @var{size}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex sum
|
2009-06-06 08:22:04 +00:00
|
|
|
Compute the checksum of a memory region.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "device_add",
|
2010-02-10 19:47:28 +00:00
|
|
|
.args_type = "device:O",
|
|
|
|
.params = "driver[,prop=value][,...]",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "add device, like -device on the command line",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_device_add,
|
2014-04-13 15:25:07 +00:00
|
|
|
.command_completion = device_add_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-09-25 19:42:41 +00:00
|
|
|
STEXI
|
|
|
|
@item device_add @var{config}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex device_add
|
2009-09-25 19:42:41 +00:00
|
|
|
Add device.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "device_del",
|
|
|
|
.args_type = "id:s",
|
|
|
|
.params = "device",
|
|
|
|
.help = "remove device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_device_del,
|
2014-04-13 15:25:07 +00:00
|
|
|
.command_completion = device_del_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-09-25 19:42:41 +00:00
|
|
|
STEXI
|
|
|
|
@item device_del @var{id}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex device_del
|
2015-09-11 12:33:56 +00:00
|
|
|
Remove device @var{id}. @var{id} may be a short ID
|
|
|
|
or a QOM object path.
|
2009-09-25 19:42:41 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "cpu",
|
|
|
|
.args_type = "index:i",
|
|
|
|
.params = "index",
|
|
|
|
.help = "set the default CPU",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_cpu,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2009-09-25 19:42:41 +00:00
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2010-05-04 11:20:32 +00:00
|
|
|
@item cpu @var{index}
|
|
|
|
@findex cpu
|
2009-06-06 08:22:04 +00:00
|
|
|
Set the default CPU.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "mouse_move",
|
|
|
|
.args_type = "dx_str:s,dy_str:s,dz_str:s?",
|
|
|
|
.params = "dx dy [dz]",
|
|
|
|
.help = "send mouse move events",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_mouse_move,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item mouse_move @var{dx} @var{dy} [@var{dz}]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex mouse_move
|
2009-06-06 08:22:04 +00:00
|
|
|
Move the active mouse to the specified coordinates @var{dx} @var{dy}
|
|
|
|
with optional scroll axis @var{dz}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "mouse_button",
|
|
|
|
.args_type = "button_state:i",
|
|
|
|
.params = "state",
|
|
|
|
.help = "change mouse button state (1=L, 2=M, 4=R)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_mouse_button,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item mouse_button @var{val}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex mouse_button
|
2009-06-06 08:22:04 +00:00
|
|
|
Change the active mouse button state @var{val} (1=L, 2=M, 4=R).
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "mouse_set",
|
|
|
|
.args_type = "index:i",
|
|
|
|
.params = "index",
|
|
|
|
.help = "set which mouse device receives events",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_mouse_set,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item mouse_set @var{index}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex mouse_set
|
2009-06-06 08:22:04 +00:00
|
|
|
Set which mouse device receives events at given @var{index}, index
|
|
|
|
can be obtained with
|
|
|
|
@example
|
|
|
|
info mice
|
|
|
|
@end example
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "wavcapture",
|
2019-08-18 23:06:48 +00:00
|
|
|
.args_type = "path:F,audiodev:s,freq:i?,bits:i?,nchannels:i?",
|
|
|
|
.params = "path audiodev [frequency [bits [channels]]]",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "capture audio to a wave file (default frequency=44100 bits=16 channels=2)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_wavcapture,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2019-08-18 23:06:48 +00:00
|
|
|
@item wavcapture @var{filename} @var{audiodev} [@var{frequency} [@var{bits} [@var{channels}]]]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex wavcapture
|
2019-08-18 23:06:48 +00:00
|
|
|
Capture audio into @var{filename} from @var{audiodev}, using sample rate
|
|
|
|
@var{frequency} bits per sample @var{bits} and number of channels
|
|
|
|
@var{channels}.
|
2009-06-06 08:22:04 +00:00
|
|
|
|
|
|
|
Defaults:
|
|
|
|
@itemize @minus
|
|
|
|
@item Sample rate = 44100 Hz - CD quality
|
|
|
|
@item Bits = 16
|
|
|
|
@item Number of channels = 2 - Stereo
|
|
|
|
@end itemize
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "stopcapture",
|
|
|
|
.args_type = "n:i",
|
|
|
|
.params = "capture index",
|
|
|
|
.help = "stop capture",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_stopcapture,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item stopcapture @var{index}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex stopcapture
|
2009-06-06 08:22:04 +00:00
|
|
|
Stop capture with a given @var{index}, index can be obtained with
|
|
|
|
@example
|
|
|
|
info capture
|
|
|
|
@end example
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "memsave",
|
|
|
|
.args_type = "val:l,size:i,filename:s",
|
|
|
|
.params = "addr size file",
|
|
|
|
.help = "save to disk virtual memory dump starting at 'addr' of size 'size'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_memsave,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item memsave @var{addr} @var{size} @var{file}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex memsave
|
2009-06-06 08:22:04 +00:00
|
|
|
save to disk virtual memory dump starting at @var{addr} of size @var{size}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "pmemsave",
|
|
|
|
.args_type = "val:l,size:i,filename:s",
|
|
|
|
.params = "addr size file",
|
|
|
|
.help = "save to disk physical memory dump starting at 'addr' of size 'size'",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_pmemsave,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item pmemsave @var{addr} @var{size} @var{file}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex pmemsave
|
2009-06-06 08:22:04 +00:00
|
|
|
save to disk physical memory dump starting at @var{addr} of size @var{size}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "boot_set",
|
|
|
|
.args_type = "bootdevice:s",
|
|
|
|
.params = "bootdevice",
|
|
|
|
.help = "define new values for the boot device list",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_boot_set,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item boot_set @var{bootdevicelist}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex boot_set
|
2009-06-06 08:22:04 +00:00
|
|
|
Define new values for the boot device list. Those values will override
|
|
|
|
the values specified on the command line through the @code{-boot} option.
|
|
|
|
|
|
|
|
The values that can be specified here depend on the machine type, but are
|
|
|
|
the same that can be specified in the @code{-boot} command line option.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "nmi",
|
2011-04-29 15:11:50 +00:00
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
2014-08-20 12:16:33 +00:00
|
|
|
.help = "inject an NMI",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_nmi,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item nmi @var{cpu}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex nmi
|
2014-08-20 12:16:33 +00:00
|
|
|
Inject an NMI on the default CPU (x86/s390) or all CPUs (ppc64).
|
2013-01-24 16:03:20 +00:00
|
|
|
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
.name = "ringbuf_write",
|
2013-01-24 16:03:20 +00:00
|
|
|
.args_type = "device:s,data:s",
|
|
|
|
.params = "device data",
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
.help = "Write to a ring buffer character device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_ringbuf_write,
|
2014-05-27 22:39:30 +00:00
|
|
|
.command_completion = ringbuf_write_completion,
|
2013-01-24 16:03:20 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
@item ringbuf_write @var{device} @var{data}
|
|
|
|
@findex ringbuf_write
|
|
|
|
Write @var{data} to ring buffer character device @var{device}.
|
|
|
|
@var{data} must be a UTF-8 string.
|
2013-01-24 16:03:20 +00:00
|
|
|
|
2013-01-24 16:03:21 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
.name = "ringbuf_read",
|
2013-01-24 16:03:21 +00:00
|
|
|
.args_type = "device:s,size:i",
|
|
|
|
.params = "device size",
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
.help = "Read from a ring buffer character device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_ringbuf_read,
|
2014-05-27 22:39:30 +00:00
|
|
|
.command_completion = ringbuf_write_completion,
|
2013-01-24 16:03:21 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
@item ringbuf_read @var{device}
|
|
|
|
@findex ringbuf_read
|
|
|
|
Read and print up to @var{size} bytes from ring buffer character
|
|
|
|
device @var{device}.
|
2013-02-06 20:27:26 +00:00
|
|
|
Certain non-printable characters are printed \uXXXX, where XXXX is the
|
|
|
|
character code in hexadecimal. Character \ is printed \\.
|
qemu-char: Saner naming of memchar stuff & doc fixes
New device, has never been released, so we can still improve things
without worrying about compatibility.
Naming is a mess. The code calls the device driver CirMemCharDriver,
the public API calls it "memory", "memchardev", or "memchar", and the
special commands are named like "memchar-FOO". "memory" is a
particularly unfortunate choice, because there's another character
device driver called MemoryDriver. Moreover, the device's distinctive
property is that it's a ring buffer, not that's in memory. Therefore:
* Rename CirMemCharDriver to RingBufCharDriver, and call the thing a
"ringbuf" in the API.
* Rename QMP and HMP commands from memchar-FOO to ringbuf-FOO.
* Rename device parameter from maxcapacity to size (simple words are
good for you).
* Clearly mark the parameter as optional in documentation.
* Fix error reporting so that chardev-add reports to current monitor,
not stderr.
* Replace cirmem in C identifiers by ringbuf.
* Rework documentation. Document the impact of our crappy UTF-8
handling on reading.
* QMP examples that even work.
I could split this up into multiple commits, but they'd change the
same documentation lines multiple times. Not worth it.
Signed-off-by: Markus Armbruster <armbru@redhat.com>
Reviewed-by: Eric Blake <eblake@redhat.com>
Signed-off-by: Anthony Liguori <aliguori@us.ibm.com>
2013-02-06 20:27:24 +00:00
|
|
|
Bug: can screw up when the buffer contains invalid UTF-8 sequences,
|
|
|
|
NUL characters, after the ring buffer lost data, and when reading
|
|
|
|
stops because the size limit is reached.
|
2013-01-24 16:03:21 +00:00
|
|
|
|
2019-02-27 13:24:12 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "announce_self",
|
2019-06-20 18:47:05 +00:00
|
|
|
.args_type = "interfaces:s?,id:s?",
|
|
|
|
.params = "[interfaces] [id]",
|
2019-02-27 13:24:12 +00:00
|
|
|
.help = "Trigger GARP/RARP announcements",
|
|
|
|
.cmd = hmp_announce_self,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item announce_self
|
|
|
|
@findex announce_self
|
|
|
|
Trigger a round of GARP/RARP broadcasts; this is useful for explicitly updating the
|
|
|
|
network infrastructure after a reconfiguration or some forms of migration.
|
|
|
|
The timings of the round are set by the migration announce parameters.
|
2019-06-20 18:47:03 +00:00
|
|
|
An optional comma separated @var{interfaces} list restricts the announce to the
|
2019-06-20 18:47:05 +00:00
|
|
|
named set of interfaces. An optional @var{id} can be used to start a separate announce
|
|
|
|
timer and to change the parameters of it later.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "migrate",
|
2018-05-02 10:47:23 +00:00
|
|
|
.args_type = "detach:-d,blk:-b,inc:-i,resume:-r,uri:s",
|
|
|
|
.params = "[-d] [-b] [-i] [-r] uri",
|
2009-11-02 13:41:13 +00:00
|
|
|
.help = "migrate to URI (using -d to not wait for completion)"
|
|
|
|
"\n\t\t\t -b for migration without shared storage with"
|
|
|
|
" full copy of disk\n\t\t\t -i for migration without "
|
|
|
|
"shared storage with incremental copy of disk "
|
2018-05-02 10:47:23 +00:00
|
|
|
"(base image shared between src and destination)"
|
|
|
|
"\n\t\t\t -r to resume a paused migration",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-11-02 13:41:13 +00:00
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2009-11-02 13:41:13 +00:00
|
|
|
@item migrate [-d] [-b] [-i] @var{uri}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex migrate
|
2009-06-06 08:22:04 +00:00
|
|
|
Migrate to @var{uri} (using -d to not wait for completion).
|
2009-11-02 13:41:13 +00:00
|
|
|
-b for migration with full copy of disk
|
|
|
|
-i for migration with incremental copy of disk (base image is shared)
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "migrate_cancel",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "cancel the current VM migration",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_cancel,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item migrate_cancel
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex migrate_cancel
|
2009-06-06 08:22:04 +00:00
|
|
|
Cancel the current VM migration.
|
2017-10-20 09:05:54 +00:00
|
|
|
ETEXI
|
2012-08-06 18:42:54 +00:00
|
|
|
|
2017-10-20 09:05:54 +00:00
|
|
|
{
|
|
|
|
.name = "migrate_continue",
|
|
|
|
.args_type = "state:s",
|
|
|
|
.params = "state",
|
|
|
|
.help = "Continue migration from the given paused state",
|
|
|
|
.cmd = hmp_migrate_continue,
|
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item migrate_continue @var{state}
|
|
|
|
@findex migrate_continue
|
|
|
|
Continue migration from the paused state @var{state}
|
2015-02-19 11:40:28 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_incoming",
|
|
|
|
.args_type = "uri:s",
|
|
|
|
.params = "uri",
|
|
|
|
.help = "Continue an incoming migration from an -incoming defer",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_incoming,
|
2015-02-19 11:40:28 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_incoming @var{uri}
|
|
|
|
@findex migrate_incoming
|
|
|
|
Continue an incoming migration using the @var{uri} (that has the same syntax
|
|
|
|
as the -incoming option).
|
2018-05-02 10:47:37 +00:00
|
|
|
ETEXI
|
2015-02-19 11:40:28 +00:00
|
|
|
|
2018-05-02 10:47:37 +00:00
|
|
|
{
|
|
|
|
.name = "migrate_recover",
|
|
|
|
.args_type = "uri:s",
|
|
|
|
.params = "uri",
|
|
|
|
.help = "Continue a paused incoming postcopy migration",
|
|
|
|
.cmd = hmp_migrate_recover,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_recover @var{uri}
|
|
|
|
@findex migrate_recover
|
|
|
|
Continue a paused incoming postcopy migration using the @var{uri}.
|
2018-05-02 10:47:40 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_pause",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "Pause an ongoing migration (postcopy-only)",
|
|
|
|
.cmd = hmp_migrate_pause,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_pause
|
|
|
|
@findex migrate_pause
|
|
|
|
Pause an ongoing migration. Currently it only supports postcopy.
|
2012-08-06 18:42:54 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_set_cache_size",
|
|
|
|
.args_type = "value:o",
|
|
|
|
.params = "value",
|
|
|
|
.help = "set cache size (in bytes) for XBZRLE migrations,"
|
|
|
|
"the cache size will be rounded down to the nearest "
|
|
|
|
"power of 2.\n"
|
|
|
|
"The cache size affects the number of cache misses."
|
|
|
|
"In case of a high cache miss ratio you need to increase"
|
|
|
|
" the cache size",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_set_cache_size,
|
2012-08-06 18:42:54 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_set_cache_size @var{value}
|
|
|
|
@findex migrate_set_cache_size
|
|
|
|
Set cache size to @var{value} (in bytes) for xbzrle migrations.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "migrate_set_speed",
|
2010-10-21 15:15:48 +00:00
|
|
|
.args_type = "value:o",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "value",
|
2010-10-21 15:15:48 +00:00
|
|
|
.help = "set maximum speed (in bytes) for migrations. "
|
|
|
|
"Defaults to MB if no size suffix is specified, ie. B/K/M/G/T",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_set_speed,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item migrate_set_speed @var{value}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex migrate_set_speed
|
2009-06-06 08:22:04 +00:00
|
|
|
Set maximum speed to @var{value} (in bytes) for migrations.
|
2009-05-28 19:22:58 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "migrate_set_downtime",
|
2010-01-25 13:23:07 +00:00
|
|
|
.args_type = "value:T",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "value",
|
|
|
|
.help = "set maximum tolerated downtime (in seconds) for migrations",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_set_downtime,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2009-05-28 19:22:58 +00:00
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_set_downtime @var{second}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex migrate_set_downtime
|
2009-05-28 19:22:58 +00:00
|
|
|
Set maximum tolerated downtime (in seconds) for migration.
|
2012-08-06 18:42:48 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_set_capability",
|
|
|
|
.args_type = "capability:s,state:b",
|
|
|
|
.params = "capability state",
|
|
|
|
.help = "Enable/Disable the usage of a capability for migration",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_set_capability,
|
2014-05-27 22:39:32 +00:00
|
|
|
.command_completion = migrate_set_capability_completion,
|
2012-08-06 18:42:48 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_set_capability @var{capability} @var{state}
|
|
|
|
@findex migrate_set_capability
|
|
|
|
Enable/Disable the usage of a capability @var{capability} for migration.
|
2015-03-23 08:32:29 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_set_parameter",
|
2016-04-27 10:05:15 +00:00
|
|
|
.args_type = "parameter:s,value:s",
|
2015-03-23 08:32:29 +00:00
|
|
|
.params = "parameter value",
|
|
|
|
.help = "Set the parameter for migration",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_set_parameter,
|
2015-03-23 08:32:29 +00:00
|
|
|
.command_completion = migrate_set_parameter_completion,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_set_parameter @var{parameter} @var{value}
|
|
|
|
@findex migrate_set_parameter
|
|
|
|
Set the parameter @var{parameter} for migration.
|
2015-11-05 18:10:56 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "migrate_start_postcopy",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
2015-11-12 11:34:44 +00:00
|
|
|
.help = "Followup to a migration command to switch the migration"
|
2016-03-11 09:53:36 +00:00
|
|
|
" to postcopy mode. The postcopy-ram capability must "
|
2018-02-07 15:41:43 +00:00
|
|
|
"be set on both source and destination before the "
|
|
|
|
"original migration command .",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_migrate_start_postcopy,
|
2015-11-05 18:10:56 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migrate_start_postcopy
|
|
|
|
@findex migrate_start_postcopy
|
|
|
|
Switch in-progress migration to postcopy mode. Ignored after the end of
|
|
|
|
migration (or once already in postcopy).
|
COLO: Add 'x-colo-lost-heartbeat' command to trigger failover
We leave users to choose whatever heartbeat solution they want,
if the heartbeat is lost, or other errors they detect, they can use
experimental command 'x_colo_lost_heartbeat' to tell COLO to do failover,
COLO will do operations accordingly.
For example, if the command is sent to the Primary side,
the Primary side will exit COLO mode, does cleanup work,
and then, PVM will take over the service work. If sent to the Secondary side,
the Secondary side will run failover work, then takes over PVM's service work.
Cc: Luiz Capitulino <lcapitulino@redhat.com>
Cc: Eric Blake <eblake@redhat.com>
Cc: Markus Armbruster <armbru@redhat.com>
Signed-off-by: zhanghailiang <zhang.zhanghailiang@huawei.com>
Signed-off-by: Li Zhijian <lizhijian@cn.fujitsu.com>
Reviewed-by: Dr. David Alan Gilbert <dgilbert@redhat.com>
Reviewed-by: Amit Shah <amit.shah@redhat.com>
Signed-off-by: Amit Shah <amit@amitshah.net>
2016-10-27 06:43:03 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "x_colo_lost_heartbeat",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "",
|
|
|
|
.help = "Tell COLO that heartbeat is lost,\n\t\t\t"
|
|
|
|
"a failover or takeover is needed.",
|
|
|
|
.cmd = hmp_x_colo_lost_heartbeat,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item x_colo_lost_heartbeat
|
|
|
|
@findex x_colo_lost_heartbeat
|
|
|
|
Tell COLO that heartbeat is lost, a failover or takeover is needed.
|
2010-12-16 12:52:16 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
2011-03-09 15:54:34 +00:00
|
|
|
.name = "client_migrate_info",
|
|
|
|
.args_type = "protocol:s,hostname:s,port:i?,tls-port:i?,cert-subject:s?",
|
|
|
|
.params = "protocol hostname port tls-port cert-subject",
|
2015-03-05 18:16:58 +00:00
|
|
|
.help = "set migration information for remote display",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_client_migrate_info,
|
2010-12-16 12:52:16 +00:00
|
|
|
},
|
|
|
|
|
2010-04-23 11:28:21 +00:00
|
|
|
STEXI
|
|
|
|
@item client_migrate_info @var{protocol} @var{hostname} @var{port} @var{tls-port} @var{cert-subject}
|
|
|
|
@findex client_migrate_info
|
2015-03-05 18:16:58 +00:00
|
|
|
Set migration information for remote display. This makes the server
|
|
|
|
ask the client to automatically reconnect using the new parameters
|
|
|
|
once migration finished successfully. Only implemented for SPICE.
|
2010-04-23 11:28:21 +00:00
|
|
|
ETEXI
|
|
|
|
|
2012-05-07 04:10:47 +00:00
|
|
|
{
|
|
|
|
.name = "dump-guest-memory",
|
2018-05-17 16:23:39 +00:00
|
|
|
.args_type = "paging:-p,detach:-d,windmp:-w,zlib:-z,lzo:-l,snappy:-s,filename:F,begin:l?,length:l?",
|
|
|
|
.params = "[-p] [-d] [-z|-l|-s|-w] filename [begin length]",
|
2014-04-17 08:15:06 +00:00
|
|
|
.help = "dump guest memory into file 'filename'.\n\t\t\t"
|
|
|
|
"-p: do paging to get guest's memory mapping.\n\t\t\t"
|
2016-02-18 05:16:47 +00:00
|
|
|
"-d: return immediately (do not wait for completion).\n\t\t\t"
|
2014-04-17 08:15:07 +00:00
|
|
|
"-z: dump in kdump-compressed format, with zlib compression.\n\t\t\t"
|
|
|
|
"-l: dump in kdump-compressed format, with lzo compression.\n\t\t\t"
|
|
|
|
"-s: dump in kdump-compressed format, with snappy compression.\n\t\t\t"
|
2018-05-17 16:23:39 +00:00
|
|
|
"-w: dump in Windows crashdump format (can be used instead of ELF-dump converting),\n\t\t\t"
|
|
|
|
" for Windows x64 guests with vmcoreinfo driver only.\n\t\t\t"
|
2014-04-17 08:15:06 +00:00
|
|
|
"begin: the starting physical address.\n\t\t\t"
|
|
|
|
"length: the memory size, in bytes.",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_dump_guest_memory,
|
2012-05-07 04:10:47 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
2014-04-17 08:15:06 +00:00
|
|
|
@item dump-guest-memory [-p] @var{filename} @var{begin} @var{length}
|
2018-05-17 16:23:39 +00:00
|
|
|
@item dump-guest-memory [-z|-l|-s|-w] @var{filename}
|
2012-05-07 04:10:47 +00:00
|
|
|
@findex dump-guest-memory
|
|
|
|
Dump guest memory to @var{protocol}. The file can be processed with crash or
|
2018-05-17 16:23:39 +00:00
|
|
|
gdb. Without -z|-l|-s|-w, the dump format is ELF.
|
2014-04-17 08:15:06 +00:00
|
|
|
-p: do paging to get guest's memory mapping.
|
2014-04-17 08:15:07 +00:00
|
|
|
-z: dump in kdump-compressed format, with zlib compression.
|
|
|
|
-l: dump in kdump-compressed format, with lzo compression.
|
|
|
|
-s: dump in kdump-compressed format, with snappy compression.
|
2018-05-17 16:23:39 +00:00
|
|
|
-w: dump in Windows crashdump format (can be used instead of ELF-dump converting),
|
|
|
|
for Windows x64 guests with vmcoreinfo driver only
|
2014-04-17 08:15:06 +00:00
|
|
|
filename: dump file name.
|
2012-05-07 04:10:47 +00:00
|
|
|
begin: the starting physical address. It's optional, and should be
|
2014-04-17 08:15:06 +00:00
|
|
|
specified together with length.
|
2012-05-07 04:10:47 +00:00
|
|
|
length: the memory size, in bytes. It's optional, and should be specified
|
2014-04-17 08:15:06 +00:00
|
|
|
together with begin.
|
2012-05-07 04:10:47 +00:00
|
|
|
ETEXI
|
|
|
|
|
2015-06-26 18:07:21 +00:00
|
|
|
#if defined(TARGET_S390X)
|
|
|
|
{
|
|
|
|
.name = "dump-skeys",
|
|
|
|
.args_type = "filename:F",
|
|
|
|
.params = "",
|
|
|
|
.help = "Save guest storage keys into file 'filename'.\n",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_dump_skeys,
|
2015-06-26 18:07:21 +00:00
|
|
|
},
|
|
|
|
#endif
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item dump-skeys @var{filename}
|
|
|
|
@findex dump-skeys
|
|
|
|
Save guest storage keys to a file.
|
2016-08-15 16:44:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
#if defined(TARGET_S390X)
|
|
|
|
{
|
|
|
|
.name = "migration_mode",
|
|
|
|
.args_type = "mode:i",
|
|
|
|
.params = "mode",
|
|
|
|
.help = "Enables or disables migration mode\n",
|
|
|
|
.cmd = hmp_migrationmode,
|
|
|
|
},
|
|
|
|
#endif
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item migration_mode @var{mode}
|
|
|
|
@findex migration_mode
|
|
|
|
Enables or disables migration mode.
|
2015-06-26 18:07:21 +00:00
|
|
|
ETEXI
|
|
|
|
|
2010-04-23 11:28:21 +00:00
|
|
|
{
|
2011-03-09 15:54:34 +00:00
|
|
|
.name = "snapshot_blkdev",
|
2012-03-06 17:55:59 +00:00
|
|
|
.args_type = "reuse:-n,device:B,snapshot-file:s?,format:s?",
|
|
|
|
.params = "[-n] device [new-image-file] [format]",
|
2011-03-09 15:54:34 +00:00
|
|
|
.help = "initiates a live snapshot\n\t\t\t"
|
|
|
|
"of device. If a new image file is specified, the\n\t\t\t"
|
|
|
|
"new image file will become the new root image.\n\t\t\t"
|
|
|
|
"If format is specified, the snapshot file will\n\t\t\t"
|
2013-09-11 06:04:37 +00:00
|
|
|
"be created in that format.\n\t\t\t"
|
2012-03-06 17:55:59 +00:00
|
|
|
"The default format is qcow2. The -n flag requests QEMU\n\t\t\t"
|
|
|
|
"to reuse the image found in new-image-file, instead of\n\t\t\t"
|
|
|
|
"recreating it from scratch.",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_snapshot_blkdev,
|
2010-04-23 11:28:21 +00:00
|
|
|
},
|
|
|
|
|
2010-12-16 12:52:16 +00:00
|
|
|
STEXI
|
|
|
|
@item snapshot_blkdev
|
|
|
|
@findex snapshot_blkdev
|
|
|
|
Snapshot device, using snapshot file as target if provided
|
2013-09-11 06:04:37 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "snapshot_blkdev_internal",
|
|
|
|
.args_type = "device:B,name:s",
|
|
|
|
.params = "device name",
|
|
|
|
.help = "take an internal snapshot of device.\n\t\t\t"
|
|
|
|
"The format of the image used by device must\n\t\t\t"
|
|
|
|
"support it, such as qcow2.\n\t\t\t",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_snapshot_blkdev_internal,
|
2013-09-11 06:04:37 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item snapshot_blkdev_internal
|
|
|
|
@findex snapshot_blkdev_internal
|
|
|
|
Take an internal snapshot on device if it support
|
2013-09-11 06:04:38 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "snapshot_delete_blkdev_internal",
|
|
|
|
.args_type = "device:B,name:s,id:s?",
|
|
|
|
.params = "device name [id]",
|
|
|
|
.help = "delete an internal snapshot of device.\n\t\t\t"
|
|
|
|
"If id is specified, qemu will try delete\n\t\t\t"
|
|
|
|
"the snapshot matching both id and name.\n\t\t\t"
|
|
|
|
"The format of the image used by device must\n\t\t\t"
|
|
|
|
"support it, such as qcow2.\n\t\t\t",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_snapshot_delete_blkdev_internal,
|
2013-09-11 06:04:38 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item snapshot_delete_blkdev_internal
|
|
|
|
@findex snapshot_delete_blkdev_internal
|
|
|
|
Delete an internal snapshot on device if it support
|
2012-10-18 14:49:24 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "drive_mirror",
|
|
|
|
.args_type = "reuse:-n,full:-f,device:B,target:s,format:s?",
|
|
|
|
.params = "[-n] [-f] device target [format]",
|
|
|
|
.help = "initiates live storage\n\t\t\t"
|
|
|
|
"migration for a device. The device's contents are\n\t\t\t"
|
|
|
|
"copied to the new image file, including data that\n\t\t\t"
|
|
|
|
"is written after the command is started.\n\t\t\t"
|
|
|
|
"The -n flag requests QEMU to reuse the image found\n\t\t\t"
|
|
|
|
"in new-image-file, instead of recreating it from scratch.\n\t\t\t"
|
|
|
|
"The -f flag requests QEMU to copy the whole disk,\n\t\t\t"
|
|
|
|
"so that the result does not need a backing file.\n\t\t\t",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_drive_mirror,
|
2012-10-18 14:49:24 +00:00
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item drive_mirror
|
|
|
|
@findex drive_mirror
|
|
|
|
Start mirroring a block device's writes to a new destination,
|
|
|
|
using the specified target.
|
2013-06-26 12:11:58 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "drive_backup",
|
2016-07-22 08:17:52 +00:00
|
|
|
.args_type = "reuse:-n,full:-f,compress:-c,device:B,target:s,format:s?",
|
|
|
|
.params = "[-n] [-f] [-c] device target [format]",
|
2013-06-26 12:11:58 +00:00
|
|
|
.help = "initiates a point-in-time\n\t\t\t"
|
|
|
|
"copy for a device. The device's contents are\n\t\t\t"
|
|
|
|
"copied to the new image file, excluding data that\n\t\t\t"
|
|
|
|
"is written after the command is started.\n\t\t\t"
|
|
|
|
"The -n flag requests QEMU to reuse the image found\n\t\t\t"
|
|
|
|
"in new-image-file, instead of recreating it from scratch.\n\t\t\t"
|
|
|
|
"The -f flag requests QEMU to copy the whole disk,\n\t\t\t"
|
2016-07-22 08:17:52 +00:00
|
|
|
"so that the result does not need a backing file.\n\t\t\t"
|
|
|
|
"The -c flag requests QEMU to compress backup data\n\t\t\t"
|
|
|
|
"(if the target format supports it).\n\t\t\t",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_drive_backup,
|
2013-06-26 12:11:58 +00:00
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item drive_backup
|
|
|
|
@findex drive_backup
|
|
|
|
Start a point-in-time copy of a block device to a specificed target.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "drive_add",
|
2016-02-23 16:33:24 +00:00
|
|
|
.args_type = "node:-n,pci_addr:s,opts:s",
|
|
|
|
.params = "[-n] [[<domain>:]<bus>:]<slot>\n"
|
2009-10-07 16:41:50 +00:00
|
|
|
"[file=file][,if=type][,bus=n]\n"
|
2011-11-17 13:40:32 +00:00
|
|
|
"[,unit=m][,media=d][,index=i]\n"
|
|
|
|
"[,snapshot=on|off][,cache=on|off]\n"
|
|
|
|
"[,readonly=on|off][,copy-on-read=on|off]",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "add drive to PCI storage controller",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_drive_add,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item drive_add
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex drive_add
|
2009-06-06 08:22:04 +00:00
|
|
|
Add drive to PCI storage controller.
|
2010-12-24 03:14:14 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "pcie_aer_inject_error",
|
|
|
|
.args_type = "advisory_non_fatal:-a,correctable:-c,"
|
|
|
|
"id:s,error_status:s,"
|
|
|
|
"header0:i?,header1:i?,header2:i?,header3:i?,"
|
|
|
|
"prefix0:i?,prefix1:i?,prefix2:i?,prefix3:i?",
|
|
|
|
.params = "[-a] [-c] id "
|
|
|
|
"<error_status> [<tlp header> [<tlp header prefix>]]",
|
|
|
|
.help = "inject pcie aer error\n\t\t\t"
|
|
|
|
" -a for advisory non fatal error\n\t\t\t"
|
|
|
|
" -c for correctable error\n\t\t\t"
|
|
|
|
"<id> = qdev device id\n\t\t\t"
|
|
|
|
"<error_status> = error string or 32bit\n\t\t\t"
|
|
|
|
"<tlb header> = 32bit x 4\n\t\t\t"
|
|
|
|
"<tlb header prefix> = 32bit x 4",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_pcie_aer_inject_error,
|
2010-12-24 03:14:14 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item pcie_aer_inject_error
|
|
|
|
@findex pcie_aer_inject_error
|
|
|
|
Inject PCIe AER error
|
2010-03-25 16:22:40 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "netdev_add",
|
|
|
|
.args_type = "netdev:O",
|
2014-06-10 10:02:16 +00:00
|
|
|
.params = "[user|tap|socket|vde|bridge|hubport|netmap|vhost-user],id=str[,prop=value][,...]",
|
2010-03-25 16:22:40 +00:00
|
|
|
.help = "add host network device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_netdev_add,
|
2014-05-07 22:41:31 +00:00
|
|
|
.command_completion = netdev_add_completion,
|
2010-03-25 16:22:40 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item netdev_add
|
|
|
|
@findex netdev_add
|
|
|
|
Add host network device.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "netdev_del",
|
|
|
|
.args_type = "id:s",
|
|
|
|
.params = "id",
|
|
|
|
.help = "remove host network device",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_netdev_del,
|
2014-05-07 22:41:32 +00:00
|
|
|
.command_completion = netdev_del_completion,
|
2010-03-25 16:22:40 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item netdev_del
|
|
|
|
@findex netdev_del
|
|
|
|
Remove host network device.
|
2013-12-20 22:21:10 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "object_add",
|
|
|
|
.args_type = "object:O",
|
|
|
|
.params = "[qom-type=]type,id=str[,prop=value][,...]",
|
|
|
|
.help = "create QOM object",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_object_add,
|
2014-04-13 15:25:06 +00:00
|
|
|
.command_completion = object_add_completion,
|
2013-12-20 22:21:10 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item object_add
|
|
|
|
@findex object_add
|
|
|
|
Create QOM object.
|
2013-12-20 22:21:09 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "object_del",
|
|
|
|
.args_type = "id:s",
|
|
|
|
.params = "id",
|
|
|
|
.help = "destroy QOM object",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_object_del,
|
2014-04-13 15:25:06 +00:00
|
|
|
.command_completion = object_del_completion,
|
2013-12-20 22:21:09 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item object_del
|
|
|
|
@findex object_del
|
|
|
|
Destroy QOM object.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
#ifdef CONFIG_SLIRP
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "hostfwd_add",
|
|
|
|
.args_type = "arg1:s,arg2:s?,arg3:s?",
|
2018-01-11 20:02:40 +00:00
|
|
|
.params = "[hub_id name]|[netdev_id] [tcp|udp]:[hostaddr]:hostport-[guestaddr]:guestport",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "redirect TCP or UDP connections from host to guest (requires -net user)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_hostfwd_add,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
2010-05-04 11:20:30 +00:00
|
|
|
#endif
|
|
|
|
STEXI
|
|
|
|
@item hostfwd_add
|
|
|
|
@findex hostfwd_add
|
|
|
|
Redirect TCP or UDP connections from host to guest (requires -net user).
|
|
|
|
ETEXI
|
2009-10-07 16:41:50 +00:00
|
|
|
|
2010-05-04 11:20:30 +00:00
|
|
|
#ifdef CONFIG_SLIRP
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "hostfwd_remove",
|
|
|
|
.args_type = "arg1:s,arg2:s?,arg3:s?",
|
2018-01-11 20:02:40 +00:00
|
|
|
.params = "[hub_id name]|[netdev_id] [tcp|udp]:[hostaddr]:hostport",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "remove host-to-guest TCP or UDP redirection",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_hostfwd_remove,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
#endif
|
|
|
|
STEXI
|
2010-05-04 11:20:30 +00:00
|
|
|
@item hostfwd_remove
|
|
|
|
@findex hostfwd_remove
|
|
|
|
Remove host-to-guest TCP or UDP redirection.
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "balloon",
|
2009-12-18 15:25:05 +00:00
|
|
|
.args_type = "value:M",
|
2009-10-07 16:41:50 +00:00
|
|
|
.params = "target",
|
2010-05-19 16:49:28 +00:00
|
|
|
.help = "request VM to change its memory allocation (in MB)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_balloon,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item balloon @var{value}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex balloon
|
2009-06-06 08:22:04 +00:00
|
|
|
Request VM to change its memory allocation to @var{value} (in MB).
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "set_link",
|
2010-03-26 08:07:10 +00:00
|
|
|
.args_type = "name:s,up:b",
|
|
|
|
.params = "name on|off",
|
2009-10-07 16:41:50 +00:00
|
|
|
.help = "change the link status of a network adapter",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_set_link,
|
2014-05-07 22:41:30 +00:00
|
|
|
.command_completion = set_link_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2010-03-26 08:07:10 +00:00
|
|
|
@item set_link @var{name} [on|off]
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex set_link
|
2010-03-26 08:07:10 +00:00
|
|
|
Switch link @var{name} on (i.e. up) or off (i.e. down).
|
2009-06-06 08:22:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "watchdog_action",
|
|
|
|
.args_type = "action:s",
|
|
|
|
.params = "[reset|shutdown|poweroff|pause|debug|none]",
|
|
|
|
.help = "change watchdog action",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_watchdog_action,
|
2014-05-27 22:39:31 +00:00
|
|
|
.command_completion = watchdog_action_completion,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
|
|
|
@item watchdog_action
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex watchdog_action
|
2009-06-06 08:22:04 +00:00
|
|
|
Change watchdog action.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "acl_show",
|
|
|
|
.args_type = "aclname:s",
|
|
|
|
.params = "aclname",
|
|
|
|
.help = "list rules in the access control list",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_acl_show,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-06 08:22:04 +00:00
|
|
|
STEXI
|
2009-06-25 06:22:08 +00:00
|
|
|
@item acl_show @var{aclname}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex acl_show
|
2009-06-25 06:22:08 +00:00
|
|
|
List all the matching rules in the access control list, and the default
|
|
|
|
policy. There are currently two named access control lists,
|
|
|
|
@var{vnc.x509dname} and @var{vnc.username} matching on the x509 client
|
|
|
|
certificate distinguished name, and SASL username respectively.
|
|
|
|
ETEXI
|
2009-06-06 08:22:04 +00:00
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "acl_policy",
|
|
|
|
.args_type = "aclname:s,policy:s",
|
|
|
|
.params = "aclname allow|deny",
|
|
|
|
.help = "set default access control list policy",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_acl_policy,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-25 06:22:08 +00:00
|
|
|
STEXI
|
2009-07-03 06:46:05 +00:00
|
|
|
@item acl_policy @var{aclname} @code{allow|deny}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex acl_policy
|
2009-06-25 06:22:08 +00:00
|
|
|
Set the default access control list policy, used in the event that
|
2009-06-06 08:22:04 +00:00
|
|
|
none of the explicit rules match. The default policy at startup is
|
2009-06-25 06:22:08 +00:00
|
|
|
always @code{deny}.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "acl_add",
|
|
|
|
.args_type = "aclname:s,match:s,policy:s,index:i?",
|
|
|
|
.params = "aclname match allow|deny [index]",
|
|
|
|
.help = "add a match rule to the access control list",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_acl_add,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-25 06:22:08 +00:00
|
|
|
STEXI
|
2010-05-04 11:20:31 +00:00
|
|
|
@item acl_add @var{aclname} @var{match} @code{allow|deny} [@var{index}]
|
|
|
|
@findex acl_add
|
2009-06-25 06:22:08 +00:00
|
|
|
Add a match rule to the access control list, allowing or denying access.
|
|
|
|
The match will normally be an exact username or x509 distinguished name,
|
|
|
|
but can optionally include wildcard globs. eg @code{*@@EXAMPLE.COM} to
|
|
|
|
allow all users in the @code{EXAMPLE.COM} kerberos realm. The match will
|
2009-06-06 08:22:04 +00:00
|
|
|
normally be appended to the end of the ACL, but can be inserted
|
2009-06-25 06:22:08 +00:00
|
|
|
earlier in the list if the optional @var{index} parameter is supplied.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "acl_remove",
|
|
|
|
.args_type = "aclname:s,match:s",
|
|
|
|
.params = "aclname match",
|
|
|
|
.help = "remove a match rule from the access control list",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_acl_remove,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-25 06:22:08 +00:00
|
|
|
STEXI
|
|
|
|
@item acl_remove @var{aclname} @var{match}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex acl_remove
|
2009-06-25 06:22:08 +00:00
|
|
|
Remove the specified match rule from the access control list.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "acl_reset",
|
|
|
|
.args_type = "aclname:s",
|
|
|
|
.params = "aclname",
|
|
|
|
.help = "reset the access control list",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_acl_reset,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-25 06:22:08 +00:00
|
|
|
STEXI
|
2010-05-04 11:20:31 +00:00
|
|
|
@item acl_reset @var{aclname}
|
|
|
|
@findex acl_reset
|
2009-06-25 06:22:08 +00:00
|
|
|
Remove all matches from the access control list, and set the default
|
2009-06-06 08:22:04 +00:00
|
|
|
policy back to @code{deny}.
|
|
|
|
ETEXI
|
|
|
|
|
2012-08-23 09:53:04 +00:00
|
|
|
{
|
|
|
|
.name = "nbd_server_start",
|
|
|
|
.args_type = "all:-a,writable:-w,uri:s",
|
|
|
|
.params = "nbd_server_start [-a] [-w] host:port",
|
|
|
|
.help = "serve block devices on the given host and port",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_nbd_server_start,
|
2012-08-23 09:53:04 +00:00
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item nbd_server_start @var{host}:@var{port}
|
|
|
|
@findex nbd_server_start
|
|
|
|
Start an NBD server on the given host and/or port. If the @option{-a}
|
|
|
|
option is included, all of the virtual machine's block devices that
|
|
|
|
have an inserted media on them are automatically exported; in this case,
|
|
|
|
the @option{-w} option makes the devices writable too.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "nbd_server_add",
|
2018-01-09 19:28:02 +00:00
|
|
|
.args_type = "writable:-w,device:B,name:s?",
|
|
|
|
.params = "nbd_server_add [-w] device [name]",
|
2012-08-23 09:53:04 +00:00
|
|
|
.help = "export a block device via NBD",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_nbd_server_add,
|
2012-08-23 09:53:04 +00:00
|
|
|
},
|
|
|
|
STEXI
|
2018-01-09 19:28:02 +00:00
|
|
|
@item nbd_server_add @var{device} [ @var{name} ]
|
2012-08-23 09:53:04 +00:00
|
|
|
@findex nbd_server_add
|
|
|
|
Export a block device through QEMU's NBD server, which must be started
|
|
|
|
beforehand with @command{nbd_server_start}. The @option{-w} option makes the
|
2018-01-09 19:28:02 +00:00
|
|
|
exported device writable too. The export name is controlled by @var{name},
|
|
|
|
defaulting to @var{device}.
|
2018-01-25 14:45:57 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "nbd_server_remove",
|
|
|
|
.args_type = "force:-f,name:s",
|
|
|
|
.params = "nbd_server_remove [-f] name",
|
|
|
|
.help = "remove an export previously exposed via NBD",
|
|
|
|
.cmd = hmp_nbd_server_remove,
|
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item nbd_server_remove [-f] @var{name}
|
|
|
|
@findex nbd_server_remove
|
|
|
|
Stop exporting a block device through QEMU's NBD server, which was
|
|
|
|
previously started with @command{nbd_server_add}. The @option{-f}
|
|
|
|
option forces the server to drop the export immediately even if
|
|
|
|
clients are connected; otherwise the command fails unless there are no
|
|
|
|
clients.
|
2012-08-23 09:53:04 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "nbd_server_stop",
|
|
|
|
.args_type = "",
|
|
|
|
.params = "nbd_server_stop",
|
|
|
|
.help = "stop serving block devices using the NBD protocol",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_nbd_server_stop,
|
2012-08-23 09:53:04 +00:00
|
|
|
},
|
|
|
|
STEXI
|
|
|
|
@item nbd_server_stop
|
|
|
|
@findex nbd_server_stop
|
|
|
|
Stop the QEMU embedded NBD server.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
|
2009-06-23 02:05:14 +00:00
|
|
|
#if defined(TARGET_I386)
|
2009-10-07 16:41:50 +00:00
|
|
|
|
|
|
|
{
|
|
|
|
.name = "mce",
|
2010-12-10 08:21:02 +00:00
|
|
|
.args_type = "broadcast:-b,cpu_index:i,bank:i,status:l,mcg_status:l,addr:l,misc:l",
|
|
|
|
.params = "[-b] cpu bank status mcgstatus addr misc",
|
|
|
|
.help = "inject a MCE on the given CPU [and broadcast to other CPUs with -b option]",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_mce,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-06-23 02:05:14 +00:00
|
|
|
#endif
|
|
|
|
STEXI
|
|
|
|
@item mce @var{cpu} @var{bank} @var{status} @var{mcgstatus} @var{addr} @var{misc}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex mce (x86)
|
2009-06-23 02:05:14 +00:00
|
|
|
Inject an MCE on the given CPU (x86 only).
|
2009-07-22 08:11:40 +00:00
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "getfd",
|
|
|
|
.args_type = "fdname:s",
|
|
|
|
.params = "getfd name",
|
|
|
|
.help = "receive a file descriptor via SCM rights and assign it a name",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_getfd,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-07-22 08:11:40 +00:00
|
|
|
STEXI
|
|
|
|
@item getfd @var{fdname}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex getfd
|
2009-07-22 08:11:40 +00:00
|
|
|
If a file descriptor is passed alongside this command using the SCM_RIGHTS
|
|
|
|
mechanism on unix sockets, it is stored using the name @var{fdname} for
|
|
|
|
later use by other monitor commands.
|
|
|
|
ETEXI
|
|
|
|
|
2009-10-07 16:41:50 +00:00
|
|
|
{
|
|
|
|
.name = "closefd",
|
|
|
|
.args_type = "fdname:s",
|
|
|
|
.params = "closefd name",
|
|
|
|
.help = "close a file descriptor previously passed via SCM rights",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_closefd,
|
2009-10-07 16:41:50 +00:00
|
|
|
},
|
|
|
|
|
2009-07-22 08:11:40 +00:00
|
|
|
STEXI
|
|
|
|
@item closefd @var{fdname}
|
2010-02-05 22:52:04 +00:00
|
|
|
@findex closefd
|
2009-07-22 08:11:40 +00:00
|
|
|
Close the file descriptor previously assigned to @var{fdname} using the
|
|
|
|
@code{getfd} command. This is only needed if the file descriptor was never
|
|
|
|
used by another monitor command.
|
2009-12-04 17:24:09 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_passwd",
|
|
|
|
.args_type = "device:B,password:s",
|
|
|
|
.params = "block_passwd device password",
|
|
|
|
.help = "set the password of encrypted block devices",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_passwd,
|
2009-12-04 17:24:09 +00:00
|
|
|
},
|
|
|
|
|
2011-11-08 05:00:31 +00:00
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item block_passwd @var{device} @var{password}
|
|
|
|
@findex block_passwd
|
|
|
|
Set the encrypted device @var{device} password to @var{password}
|
2017-06-23 16:24:16 +00:00
|
|
|
|
|
|
|
This command is now obsolete and will always return an error since 2.10
|
2011-11-08 05:00:31 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "block_set_io_throttle",
|
|
|
|
.args_type = "device:B,bps:l,bps_rd:l,bps_wr:l,iops:l,iops_rd:l,iops_wr:l",
|
|
|
|
.params = "device bps bps_rd bps_wr iops iops_rd iops_wr",
|
|
|
|
.help = "change I/O throttle limits for a block drive",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_block_set_io_throttle,
|
2011-11-08 05:00:31 +00:00
|
|
|
},
|
|
|
|
|
2009-12-04 17:24:09 +00:00
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item block_set_io_throttle @var{device} @var{bps} @var{bps_rd} @var{bps_wr} @var{iops} @var{iops_rd} @var{iops_wr}
|
|
|
|
@findex block_set_io_throttle
|
2018-03-09 14:11:07 +00:00
|
|
|
Change I/O throttle limits for a block drive to @var{bps} @var{bps_rd} @var{bps_wr} @var{iops} @var{iops_rd} @var{iops_wr}.
|
|
|
|
@var{device} can be a block device name, a qdev ID or a QOM path.
|
2010-10-07 10:22:54 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "set_password",
|
|
|
|
.args_type = "protocol:s,password:s,connected:s?",
|
|
|
|
.params = "protocol password action-if-connected",
|
|
|
|
.help = "set spice/vnc password",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_set_password,
|
2010-10-07 10:22:54 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item set_password [ vnc | spice ] password [ action-if-connected ]
|
|
|
|
@findex set_password
|
|
|
|
Change spice/vnc password. Use zero to make the password stay valid
|
|
|
|
forever. @var{action-if-connected} specifies what should happen in
|
|
|
|
case a connection is established: @var{fail} makes the password change
|
|
|
|
fail. @var{disconnect} changes the password and disconnects the
|
|
|
|
client. @var{keep} changes the password and keeps the connection up.
|
|
|
|
@var{keep} is the default.
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "expire_password",
|
|
|
|
.args_type = "protocol:s,time:s",
|
|
|
|
.params = "protocol time",
|
|
|
|
.help = "set spice/vnc password expire-time",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_expire_password,
|
2010-10-07 10:22:54 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item expire_password [ vnc | spice ] expire-time
|
|
|
|
@findex expire_password
|
|
|
|
Specify when a password for spice/vnc becomes
|
|
|
|
invalid. @var{expire-time} accepts:
|
|
|
|
|
|
|
|
@table @var
|
|
|
|
@item now
|
|
|
|
Invalidate password instantly.
|
|
|
|
|
|
|
|
@item never
|
|
|
|
Password stays valid forever.
|
|
|
|
|
|
|
|
@item +nsec
|
|
|
|
Password stays valid for @var{nsec} seconds starting now.
|
|
|
|
|
|
|
|
@item nsec
|
|
|
|
Password is invalidated at the given time. @var{nsec} are the seconds
|
|
|
|
passed since 1970, i.e. unix epoch.
|
|
|
|
|
|
|
|
@end table
|
2012-12-19 09:33:40 +00:00
|
|
|
ETEXI
|
|
|
|
|
2013-02-28 07:46:10 +00:00
|
|
|
{
|
|
|
|
.name = "chardev-add",
|
|
|
|
.args_type = "args:s",
|
|
|
|
.params = "args",
|
|
|
|
.help = "add chardev",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_chardev_add,
|
2014-05-07 22:41:29 +00:00
|
|
|
.command_completion = chardev_add_completion,
|
2013-02-28 07:46:10 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item chardev-add args
|
|
|
|
@findex chardev-add
|
2017-07-06 12:08:57 +00:00
|
|
|
chardev-add accepts the same parameters as the -chardev command line switch.
|
|
|
|
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "chardev-change",
|
|
|
|
.args_type = "id:s,args:s",
|
|
|
|
.params = "id args",
|
|
|
|
.help = "change chardev",
|
|
|
|
.cmd = hmp_chardev_change,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item chardev-change args
|
|
|
|
@findex chardev-change
|
|
|
|
chardev-change accepts existing chardev @var{id} and then the same arguments
|
|
|
|
as the -chardev command line switch (except for "id").
|
2013-02-28 07:46:10 +00:00
|
|
|
|
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "chardev-remove",
|
|
|
|
.args_type = "id:s",
|
|
|
|
.params = "id",
|
|
|
|
.help = "remove chardev",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_chardev_remove,
|
2014-05-07 22:41:28 +00:00
|
|
|
.command_completion = chardev_remove_completion,
|
2013-02-28 07:46:10 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
2015-03-10 12:23:04 +00:00
|
|
|
@item chardev-remove id
|
|
|
|
@findex chardev-remove
|
2013-02-28 07:46:10 +00:00
|
|
|
Removes the chardev @var{id}.
|
|
|
|
|
2017-06-11 07:48:17 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "chardev-send-break",
|
|
|
|
.args_type = "id:s",
|
|
|
|
.params = "id",
|
|
|
|
.help = "send a break on chardev",
|
|
|
|
.cmd = hmp_chardev_send_break,
|
|
|
|
.command_completion = chardev_remove_completion,
|
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item chardev-send-break id
|
|
|
|
@findex chardev-send-break
|
|
|
|
Send a break on the chardev @var{id}.
|
|
|
|
|
2013-06-05 12:19:41 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "qemu-io",
|
2019-12-17 14:13:34 +00:00
|
|
|
.args_type = "qdev:-d,device:B,command:s",
|
|
|
|
.params = "[-d] [device] \"[command]\"",
|
|
|
|
.help = "run a qemu-io command on a block device\n\t\t\t"
|
|
|
|
"-d: [device] is a device ID rather than a "
|
|
|
|
"drive ID or node name",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_qemu_io,
|
2013-06-05 12:19:41 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item qemu-io @var{device} @var{command}
|
|
|
|
@findex qemu-io
|
|
|
|
Executes a qemu-io command on the given block device.
|
|
|
|
|
2013-12-11 18:24:14 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "cpu-add",
|
|
|
|
.args_type = "id:i",
|
|
|
|
.params = "id",
|
2018-10-30 12:35:25 +00:00
|
|
|
.help = "add cpu (deprecated, use device_add instead)",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_cpu_add,
|
2013-12-11 18:24:14 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item cpu-add @var{id}
|
2015-03-10 12:23:04 +00:00
|
|
|
@findex cpu-add
|
2018-10-30 12:35:25 +00:00
|
|
|
Add CPU with id @var{id}. This command is deprecated, please
|
|
|
|
+use @code{device_add} instead. For details, refer to
|
|
|
|
'docs/cpu-hotplug.rst'.
|
2014-05-07 16:08:29 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "qom-list",
|
|
|
|
.args_type = "path:s?",
|
|
|
|
.params = "path",
|
|
|
|
.help = "list QOM properties",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_qom_list,
|
2018-06-20 15:39:45 +00:00
|
|
|
.flags = "p",
|
2014-05-07 16:08:29 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item qom-list [@var{path}]
|
|
|
|
Print QOM properties of object at location @var{path}
|
2014-05-07 17:48:15 +00:00
|
|
|
ETEXI
|
|
|
|
|
|
|
|
{
|
|
|
|
.name = "qom-set",
|
|
|
|
.args_type = "path:s,property:s,value:s",
|
|
|
|
.params = "path property value",
|
|
|
|
.help = "set QOM property",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_qom_set,
|
2018-06-20 15:39:45 +00:00
|
|
|
.flags = "p",
|
2014-05-07 17:48:15 +00:00
|
|
|
},
|
|
|
|
|
|
|
|
STEXI
|
|
|
|
@item qom-set @var{path} @var{property} @var{value}
|
|
|
|
Set QOM property @var{property} of object at location @var{path} to value @var{value}
|
2013-02-28 07:46:10 +00:00
|
|
|
ETEXI
|
2010-05-31 17:43:31 +00:00
|
|
|
|
2010-05-31 17:43:30 +00:00
|
|
|
{
|
|
|
|
.name = "info",
|
|
|
|
.args_type = "item:s?",
|
|
|
|
.params = "[subcommand]",
|
|
|
|
.help = "show various information about the system state",
|
2016-09-12 09:19:06 +00:00
|
|
|
.cmd = hmp_info_help,
|
2019-06-13 15:33:56 +00:00
|
|
|
.sub_table = hmp_info_cmds,
|
2018-06-20 15:39:45 +00:00
|
|
|
.flags = "p",
|
2010-05-31 17:43:30 +00:00
|
|
|
},
|
|
|
|
|
2015-09-10 15:39:00 +00:00
|
|
|
STEXI
|
|
|
|
@end table
|
|
|
|
ETEXI
|