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

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.

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