ping...
On Fri, 2014-05-30 at 14:54 +0800, Chen Fan wrote:
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.fnst(a)cn.fujitsu.com>
---
tools/virsh.pod | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index de9a4f7..8d77a2f 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -1238,6 +1238,11 @@ 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.
+In particular, some hypervisors support having this migration hostname specified
+separately by setting 'migration_host' in definition file, if
'migration_host'
+is specified, the hostname or IP address will be used to as the default
I<migrateuri>
+while running migration from source host. if 'migration_host' is not specified,
+the migration hostname is set to the host's configured hostname by default.
There are a few scenarios where specifying I<migrateuri> may help:
=over 4
@@ -1251,7 +1256,9 @@ explicitly specified, using an IP address, or a correct hostname.
interfaces, it might be desirable for the migration data stream to be sent over
a specific interface for either security or performance reasons. In this case
I<migrateuri> should be explicitly specified, using an IP address associated
-with the network to be used.
+with the network to be used. In particular, Some hypervisors could be easy to
+specify the default network interface by setting 'migration_host'. then the
+I<migrateuri> can be omitted.
=item * The firewall restricts what ports are available. When libvirt generates
a migration URI, it will pick a port number using hypervisor specific rules.