4:49 a.m.
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 | 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
10:23 p.m.
Chen-san,
Looks good to me.
Thanks,
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 | 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
--
Yasunori Goto <y-goto(a)jp.fujitsu.com>
9:50 a.m.
On 06/09/2014 03:49 AM, Chen Fan wrote:
the 'migration_host' description maybe have a bit of
difficulty to
understand for user, so add this manual for them.
s/maybe have a bit of difficulty/may be a bit difficult/
Signed-off-by: Chen Fan <chen.fan.fnst(a)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).
s/tansfer/transfer/
Actually, this was rather confusing to me. Would it be better to just
simplify this section to instead point to
http://libvirt.org/migration.html#uris, rather than trying to rehash
that information incompletely?
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
s/migrateion/migration/
+hosts has multiple network interface). if the
"migrateion_host" is not specified
and again
+too, libvirt will automatically determine the hypervisor specific
URI, by looking
+up the target host's configured hostname.
Sounds redundant with the previous paragraph left in place.
I'll propose a v3.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
9:52 a.m.
New subject: [libvirt] [PATCH v3] virsh: Add details about specified migration host
From: Chen Fan <chen.fan.fnst(a)cn.fujitsu.com>
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(a)cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
tools/virsh.pod | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
diff --git a/tools/virsh.pod b/tools/virsh.pod
index 80501f9..b2fd53b 100644
--- a/tools/virsh.pod
+++ b/tools/virsh.pod
@@ -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
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
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
@@ -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
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
has different semantics:
@@ -1239,7 +1243,11 @@ 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.
+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:
=over 4
@@ -1264,6 +1272,9 @@ order to comply with local firewall policies.
=back
+See L<http://libvirt.org/migration.html#uris> for more details on
+migration URIs.
+
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
--
1.9.3
10:35 a.m.
New subject: [libvirt] [PATCH v3] virsh: Add details about specified migration host
On Tue, Jun 10, 2014 at 08:52:19AM -0600, Eric Blake wrote:
From: Chen Fan <chen.fan.fnst(a)cn.fujitsu.com>
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(a)cn.fujitsu.com>
Signed-off-by: Eric Blake <eblake(a)redhat.com>
---
tools/virsh.pod | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
This version looks better, ACK.
Martin
12:21 p.m.
New subject: [libvirt] [PATCH v3] virsh: Add details about specified migration host
On 06/10/2014 09:35 AM, Martin Kletzander wrote:
On Tue, Jun 10, 2014 at 08:52:19AM -0600, Eric Blake wrote:
> From: Chen Fan <chen.fan.fnst(a)cn.fujitsu.com>
>
> 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(a)cn.fujitsu.com>
> Signed-off-by: Eric Blake <eblake(a)redhat.com>
> ---
> tools/virsh.pod | 17 ++++++++++++++---
> 1 file changed, 14 insertions(+), 3 deletions(-)
>
This version looks better, ACK.
Pushed.
--
Eric Blake eblake redhat com +1-919-301-3266
Libvirt virtualization library http://libvirt.org
3818
days inactive
3819
days old
5 comments
4 participants
participants (4)
-
Chen Fan -
Eric Blake -
Martin Kletzander -
Yasunori Goto