the 'migration_host' description maybe have a bit of difficulty to understand for user, so add this manual for them.
Signed-off-by: Chen Fan <chen.fan.f...@cn.fujitsu.com> --- tools/virsh.pod | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/tools/virsh.pod b/tools/virsh.pod index 02671b4..7b30292 100644 --- a/tools/virsh.pod +++ b/tools/virsh.pod @@ -1208,7 +1208,8 @@ 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. 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<migrateuri> is the migration URI for specifying which IP address/URI of the +destination host to tansfer migration data, which usually can be omitted (see below). 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 @@ -1238,6 +1239,15 @@ seen from the source machine. When I<migrateuri> is not specified, libvirt will automatically determine the hypervisor specific URI, by looking up the target host's configured hostname. + +For QEMU/KVM hypervisor, when I<migrateuri> is not specified, at first libvirt +will ask the destination side whether the optional "migration_host" is specified +or not, if the "migration_host" is specified, libvirt will use the specified +network for transferring migration data(the "migrateion_host" is useful when +hosts has multiple network interface). if the "migrateion_host" is not specified +too, libvirt will automatically determine the hypervisor specific URI, by looking +up the target host's configured hostname. + There are a few scenarios where specifying I<migrateuri> may help: =over 4 -- 1.9.3 -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
