[Libvir] [PATCH 1/2] virDomainMigrate implementation (Xen only, no remote, no qemu, no virsh)

[Daniel P. Berrange]

On Mon, Jul 16, 2007 at 03:57:19PM -0400, Daniel Veillard wrote:
> On Mon, Jul 16, 2007 at 06:52:15PM +0100, Richard W.M. Jones wrote:
> > Daniel P. Berrange wrote:
> > >On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:
> > >>Dan Berrange wrote:
> > >>>I don't see the point in this. Libvirt already knows both hostnames
> > >>>of the source & destination.
> > >>It's really very hard for libvirt to accurately determine the hostname 
> > >>of the destination as seen from the source.  Consider the case where you 
> > >>have a multi-homed host with a generic hostname (eg. 
> > >>"localhost.localdomain" which for some reason is the default on all my 
> > >>F7 installs).  If you have a specific suggestion for how to solve this, 
> > >>I'd like to hear it.
> > >
> > >Nope don't have any magic solution offhand. I know its very hard, but
> > >punting this problem off to the end user isn't too nice either. Since
> > >we've already asked them for 2 hostnames when connecting to the source
> > >and destination nodes they would not unreasonably expect to be able
> > >to migrate without entering yet more hostnames.  
> > 
> > In the first implementation, passing hostname = NULL causes libvirt to 
> > internally do a call to virConnectGetHostname.  In src/libvirt.c:
> > 
> >     /* Synthesize a hostname if one is not given. */
> >     if (!hostname) {
> >         nchostname = virConnectGetHostname (dconn);
> >         if (!nchostname) return NULL;
> >     }
> > 
> >     /* Try to migrate. */
> >     ddomain = conn->driver->domainMigrate
> >        (domain, dconn, flags,
> >         dname,
> >         hostname ? hostname : nchostname,
> >         params);
> > 
> > Most of the drivers implement virConnectGetHostname by calling 
> > gethostname(2) which is not a very reliable way to get a hostname, 
> > unless the system is being properly administered.  (Since dconn is 
> > almost certainly going to be a remote connection, virConnectGetHostname 
> > in effect does gethostname(2) on the remote destination host).
> 
>   IMHO it suffice to get to the IP address to implement the call unless
> I'm mistaken. That is if we get something like localhost internaly 
> try to get the IP and transmit that back to the invocation point.
> I really think we should try to get without much added parameter except
> maybe the bandwidth limit.

Which IP address exactly ....

# ip addr show | grep inet
    inet 127.0.0.1/8 scope host lo
    inet6 ::1/128 scope host 
    inet 10.13.7.47/22 brd 10.13.7.255 scope global eth0
    inet6 fec0::3:216:76ff:fed6:c945/64 scope site dynamic 
    inet6 fe80::216:76ff:fed6:c945/64 scope link 
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link 
    inet 192.168.122.1/24 brd 192.168.122.255 scope global virbr0
    inet6 fe80::200:ff:fe00:0/64 scope link 
    inet6 fe80::fcff:ffff:feff:ffff/64 scope link 
    inet 10.13.5.195/22 brd 10.13.7.255 scope global eth1
    inet6 fec0::3:20e:cff:feb3:550/64 scope site dynamic 
    inet6 fe80::20e:cff:feb3:550/64 scope link 
    inet6 fec0::3:604b:fbff:fe53:86f8/64 scope site dynamic 
    inet6 fec0::3:9887:56ff:fef7:1119/64 scope site dynamic 
    inet6 fec0::3:5450:f8ff:fec8:934c/64 scope site dynamic 
    inet6 fec0::3:acb1:d4ff:fe88:2df1/64 scope site dynamic 
    inet6 fec0::3:7495:17ff:fe8a:edb/64 scope site dynamic 
    inet6 fec0::3:8c50:5ff:fef5:1ad4/64 scope site dynamic 
    inet6 fec0::3:fcff:ffff:feff:ffff/64 scope site dynamic 
    inet6 fe80::200:ff:fe00:0/64 scope link 
    inet6 fe80::604b:fbff:fe53:86f8/64 scope link 

I think best we can do is use 'gethostname()' and say that admin must have
set this up to reflect the public facing hostname. If they don't do that,
then they'll have to explicitly provide a URI for the destination instead
of (or as well as) the virConnectPtr of the target.

> > >migrate, unless someone knows of a compelling reason to require offline
> > >migration too.
> > 
> > Right, so absence of the VIR_MIGRATE_LIVE flag was meant to mean 
> > "offline".  There isn't another form of migration is there?
> 
>   I assume that Save/transmit/Restore combination doesn't count :-)

That's basically the manual way of doing offline migration.

Dan
-- 
|=- Red Hat, Engineering, Emerging Technologies, Boston.  +1 978 392 2496 -=|
|=-           Perl modules: http://search.cpan.org/~danberr/              -=|
|=-               Projects: http://freshmeat.net/~danielpb/               -=|
|=-  GnuPG: 7D3B9505   F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505  -=|