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@xxxxxxxxxx +1-919-301-3266 Libvirt virtualization library http://libvirt.org
Attachment:
signature.asc
Description: OpenPGP digital signature
-- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list