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

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

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.

>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?