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

[Daniel Veillard]

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.

> My latest thinking is that this should be a URI rather than a hostname, 
> although a naked hostname or hostname:port should be acceptable.  If URI 
> is passed as NULL, libvirt should make a best-effort attempt to 
> determine the destination hostname, although in practice this will still 
> be by calling virConnectGetHostname, unless you can think of something 
> better to do.

  I would prefer to do a couple extra RPC roundtrip and avoid extra arguments.
And if getting the IP is one of them, so be it.

> >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 :-)

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard at redhat.com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/