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&gt; > --- > 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.

On Fri, 2014-06-06 at 15:57 +0900, Yasunori Goto wrote: > Chen-san, > > > ping... > > I suppose it seems to be difficult for users to understand... > I think following order of description is desirable. > > - What is migrateuri? > - What is benefit? > - If it is ommited, what is happen? > The case of "migration_host" is specified. > The case of nothing specified > > How is the following example? I hope it is good hint for you. > (I'm newbie of man page of virsh, and may be I misunderstand migrateuri/migration_host. > So please check and correct it.) > > --- > diff --git a/tools/virsh.pod b/tools/virsh.pod > index 02671b4..0ce0ca4 100644 > --- a/tools/virsh.pod > +++ b/tools/virsh.pod > @@ -1236,9 +1236,8 @@ seen from the source machine. > > =back > > -When I<migrateuri> is not specified, 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: > +I<migrateuri> is specifed for which IP/URL is used for transfer migration data. > +Specifying I<migrateuri> may be helpful on some scenarios. > > =over 4 > > @@ -1262,6 +1261,15 @@ order to comply with local firewall policies. > > =back > > +When I<migrateuri> is not specified, libvirt will ask destination side whether > +"migration_host" is specified or not in qemu.conf at first. If "migration_host" > +is specified in qemu.conf, libvirt will use its network for transfer migration data. > +("migration_host" is useful when hosts has multiple network interface.) I think directly pointing out the specific file 'qemu.conf' is not good idea. because virsh man page is for all hypervisors including Xen, LXC, etc.

I think it should be said "For QEMU/KVM" to be better.

Thanks, Chen > + > +If "migration_host" is not specified too, then libvirt will automatically > +determine the hypervisor specific URI, by looking up the target host's > +configured hostname. > + > Optional I<graphicsuri> overrides connection parameters used for automatically > 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 > -- > > Thanks, > > > > > 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&gt; > > > --- > > > 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. > > >