Some virsh commands start a (long-running) job that can be monitored
using domjobinfo and aborted with domjobabort. Let's be explicit about
this in virsh man page.
---
tools/virsh.pod | 18 ++++++++++++++++++
1 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 43ed1ea..fbde57f 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -627,30 +627,35 @@ named by I<format> to a domain XML format.
Convert the file I<xml> in domain XML format to the native guest
configuration format named by I<format>.
=item B<dump> I<domain-id> I<corefilepath> [I<--live>] [I<--crash>]
[I<--bypass-cache>]
Dumps the core of a domain to a file for analysis.
If I<--live> is specified, the domain continues to run until the core
dump is complete, rather than pausing up front.
If I<--crash> is specified, the domain is halted with a crashed status,
rather than merely left in a paused state.
If I<--bypass-cache> is specified, the save will avoid the file system
cache, although this may slow down the operation.
+The progress may be monitored using B<domjobinfo> virsh command and canceled
+with B<domjobabort> command (sent by another virsh instance). Interrupting
+(usually with C<Ctrl-C>) the virsh process which runs B<dump> command is not
+enough to actually cancel the operation.
+
NOTE: Some hypervisors may require the user to manually ensure proper
permissions on file and path specified by argument I<corefilepath>.
=item B<dumpxml> I<domain-id> [I<--inactive>] [I<--security-info>]
[I<--update-cpu>]
Output the domain information as an XML dump to stdout, this format can be used
by the B<create> command. Additional options affecting the XML dump may be
used. I<--inactive> tells virsh to dump domain configuration that will be used
on next start of the domain as opposed to the current domain configuration.
Using I<--security-info> will also include security sensitive information
in the XML dump. I<--update-cpu> updates domain CPU requirements according to
host CPU.
=item B<echo> [I<--shell>] [I<--xml>] [I<arg>...]
@@ -672,30 +677,35 @@ This is equivalent to:
except that it does some error checking.
The editor used can be supplied by the C<$VISUAL> or C<$EDITOR> environment
variables, and defaults to C<vi>.
=item B<managedsave> I<domain-id> [I<--bypass-cache>]
[{I<--running> | I<--paused>}]
Save and destroy (stop) a running domain, so it can be restarted from the same
state at a later time. When the virsh B<start> command is next run for
the domain, it will automatically be started from this saved state.
If I<--bypass-cache> is specified, the save will avoid the file system
cache, although this may slow down the operation.
+The progress may be monitored using B<domjobinfo> virsh command and canceled
+with B<domjobabort> command (sent by another virsh instance). Interrupting
+(usually with C<Ctrl-C>) the virsh process which runs B<managedsave> command
+is not enough to actually cancel the operation.
+
Normally, starting a managed save will decide between running or paused
based on the state the domain was in when the save was done; passing
either the I<--running> or I<--paused> flag will allow overriding which
state the B<start> should use.
The B<dominfo> command can be used to query whether a domain currently
has any managed save image.
=item B<managedsave-remove> I<domain-id>
Remove the B<managedsave> state file for a domain, if it exists. This
ensures the domain will do a full boot the next time it is started.
=item B<maxvcpus> [I<type>]
@@ -724,30 +734,33 @@ used to reject the migration if the hypervisor lacks change protection
support. I<--verbose> displays the progress of migration.
The I<desturi> is the connection URI of the destination host, and
I<migrateuri> is the migration URI, which usually can be omitted.
I<dname> is used for renaming the domain to new name during migration, which
also usually can be omitted. Likewise, I<--xml> B<file> is usually
omitted, but can be used to supply an alternative XML file for use on
the destination to supply a larger set of changes to any host-specific
portions of the domain XML, such as accounting for naming differences
between source and destination in accessing underlying storage.
I<--timeout> B<seconds> forces guest to suspend when live migration exceeds
that many seconds, and
then the migration will complete offline. It can only be used with I<--live>.
+Running migration can be canceled by interrupting virsh (usually using
+C<Ctrl-C>) or by B<domjobabort> command sent from another virsh instance.
+
B<Note>: The I<desturi> parameter for normal migration and peer2peer migration
has different semantics:
=over 4
=item * normal migration: the I<desturi> is an address of the target host as
seen from the client machine.
=item * peer2peer migration: the I<desturi> is an address of the target host as
seen from the source machine.
=back
=item B<migrate-setmaxdowntime> I<domain-id> I<downtime>
@@ -797,30 +810,35 @@ B<Note>: To avoid corrupting file system contents within the domain, you
should not reuse the saved state file for a second B<restore> unless you
have also reverted all storage volumes back to the same contents as when
the state file was created.
=item B<save> I<domain-id> I<state-file> [I<--bypass-cache>] [I<--xml> B<file>]
[{I<--running> | I<--paused>}]
Saves a running domain (RAM, but not disk state) to a state file so that
it can be restored
later. Once saved, the domain will no longer be running on the
system, thus the memory allocated for the domain will be free for
other domains to use. B<virsh restore> restores from this state file.
If I<--bypass-cache> is specified, the save will avoid the file system
cache, although this may slow down the operation.
+The progress may be monitored using B<domjobinfo> virsh command and canceled
+with B<domjobabort> command (sent by another virsh instance). Interrupting
+(usually with C<Ctrl-C>) the virsh process which runs B<save> command is not
+enough to actually cancel the operation.
+
This is roughly equivalent to doing a hibernate on a running computer,
with all the same limitations. Open network connections may be
severed upon restore, as TCP timeouts may have expired.
I<--xml> B<file> is usually omitted, but can be used to supply an
alternative XML file for use on the restored guest with changes only
in the host-specific portions of the domain XML. For example, it can
be used to account for file naming differences that are planned to
be made via disk snapshots of underlying storage after the guest is saved.
Normally, restoring a saved image will decide between running or paused
based on the state the domain was in when the save was done; passing
either the I<--running> or I<--paused> flag will allow overriding which
state the B<restore> should use.
--
1.7.6.1
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list