External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-22 05:35:25 +00:00
Code Issues Packages Projects Releases Wiki Activity

docs: mention migration issue of which credentials are used

Browse Source 
Based on a report by Seth Vidal.  Just because _you_ can use virsh
to connect to both source and destinations does not mean that libvirtd
on the source (aka _root_) can likewise connect to the destination;
this matters when setting up a peer-to-peer migration instead of a
native one.

* docs/migration.html.in: Mention that in peer-to-peer, the owner
of the source libvirtd (usually root) must be able to connect to
the destination.
This commit is contained in:
Eric Blake 2012-04-30 14:51:07 -06:00
parent eecee94c3a
commit 38bd605b71
1 changed files with 18 additions and 4 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

22
docs/migration.html.in
View File

@ -87,7 +87,13 @@
daemon controls the entire migration process itself, by directly
connecting the destination host libvirtd. If the client application crashes,
or otherwise loses its connection to libvirtd, the migration process
will continue uninterrupted until completion.
will continue uninterrupted until completion. Note that the
source libvirtd uses its own credentials (typically root) to
connect to the destination, rather than the credentials used
by the client to connect to the source; if these differ, it is
common to run into a situation where a client can connect to the
destination directly but the source cannot make the connection to
set up the peer-to-peer migration.
</p>
<p>
@ -139,7 +145,9 @@
connection to the source host, where the virtual guest is
currently running. The second URI is that of the libvirt
connection to the destination host, where the virtual guest
will be moved to. The third URI is a hypervisor specific
will be moved to (and in peer-to-peer migrations, this is from
the perspective of the source, not the client). The third URI is
a hypervisor specific
URI used to control how the guest will be migrated. With
any managed migration flow, the first and second URIs are
compulsory, while the third URI is optional. With the
@ -533,7 +541,10 @@
destination libvirtd server will automatically determine
the native hypervisor URI for migration, based off the
primary hostname. There is no scope for forcing an alternative
network interface for the native migration data with this method.
network interface for the native migration data with this
method. The destination URI must be reachable using the source
libvirtd credentials (which are not necessarily the same as the
credentials of the client in connecting to the source).
</p>
<pre>
@ -571,7 +582,10 @@
in case it is not accessible using the same address that
the client uses to connect to the destination, or a different
encryption/auth scheme is required. The native hypervisor URI
format is not used at all.
format is not used at all. The destination URI must be
reachable using the source libvirtd credentials (which are not
necessarily the same as the credentials of the client in
connecting to the source).
</p>
<pre>