External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2025-02-02 01:45:17 +00:00
Code Issues Packages Projects Releases Wiki Activity

virsh: Add details about specified migration host

Browse Source 
the 'migration_host' description may be a bit difficult to
understand for some users, so enhance the manual

Signed-off-by: Chen Fan <chen.fan.fnst@cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake@redhat.com>
This commit is contained in:
Chen Fan 2014-06-09 17:49:22 +08:00 committed by Eric Blake
parent b298025063
commit c85b09cd7a
1 changed files with 14 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

17
tools/virsh.pod
View File

@ -1209,8 +1209,6 @@ unsafe unless the disk images are stored on coherent clustered filesystem,
such as GFS2 or GPFS. If you are sure the migration is safe or you just do not such as GFS2 or GPFS. If you are sure the migration is safe or you just do not
care, use I<--unsafe> to force the migration. care, use I<--unsafe> to force the migration.
The I<desturi> is the connection URI of the destination host, and
I<migrateuri> is the migration URI, which usually can be omitted (see below).
I<dname> is used for renaming the domain to new name during migration, which 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 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 omitted, but can be used to supply an alternative XML file for use on
@ -1225,6 +1223,12 @@ then the migration will complete offline. It can only be used with I<--live>.
Running migration can be canceled by interrupting virsh (usually using Running migration can be canceled by interrupting virsh (usually using
C<Ctrl-C>) or by B<domjobabort> command sent from another virsh instance. C<Ctrl-C>) or by B<domjobabort> command sent from another virsh instance.
The I<desturi> and I<migrateuri> parameters can be used to control which
destination the migration uses. I<desturi> is important for managed
migration, but unused for direct migration; I<migrateuri> is required
for direct migration, but can usually be automatically determined for
managed migration.
B<Note>: The I<desturi> parameter for normal migration and peer2peer migration B<Note>: The I<desturi> parameter for normal migration and peer2peer migration
has different semantics: has different semantics:
@ -1239,7 +1243,11 @@ seen from the source machine.
=back =back
When I<migrateuri> is not specified, libvirt will automatically determine the When I<migrateuri> is not specified, libvirt will automatically determine the
hypervisor specific URI, by looking up the target host's configured hostname. hypervisor specific URI. Some hypervisors, including QEMU, have an optional
"migration_host" configuration parameter (useful when the host has multiple
network interfaces). If this is unspecified, libvirt determines a name
by looking up the target host's configured hostname.
There are a few scenarios where specifying I<migrateuri> may help: There are a few scenarios where specifying I<migrateuri> may help:
=over 4 =over 4
@ -1264,6 +1272,9 @@ order to comply with local firewall policies.
=back =back
See L<http://libvirt.org/migration.html#uris> for more details on
migration URIs.
Optional I<graphicsuri> overrides connection parameters used for automatically Optional I<graphicsuri> overrides connection parameters used for automatically
reconnecting a graphical clients at the end of migration. If omitted, libvirt reconnecting a graphical clients at the end of migration. If omitted, libvirt
will compute the parameters based on target host IP address. In case the will compute the parameters based on target host IP address. In case the