[libvirt] [PATCH] docs: mention migration issue of which credentials are used

[Eric Blake]

ping

On 04/30/2012 02:54 PM, Eric Blake wrote:
> 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.
> ---
>  docs/migration.html.in |   22 ++++++++++++++++++----
>  1 files changed, 18 insertions(+), 4 deletions(-)
> 
> diff --git a/docs/migration.html.in b/docs/migration.html.in
> index 9d9d9b9..6a0483d 100644
> --- a/docs/migration.html.in
> +++ b/docs/migration.html.in
> @@ -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 to connect to the
> +      destination (typically root), rather than the credentials used
> +      by the client to connect to the host; if these differ, it is
> +      common to run into a situation where a client can connect to the
> +      destination directly but the host 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>

-- 
Eric Blake   eblake at redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 620 bytes
Desc: OpenPGP digital signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20120509/5838bb01/attachment-0001.sig>