Daniel P. Berrange wrote:
On Mon, Jul 16, 2007 at 04:56:53PM +0100, Richard W.M. Jones wrote:Dan Berrange wrote: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.I don't see the point in this. Libvirt already knows both hostnames of the source & destination.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 ableto 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.
Probably need one of the 'flags' to indicate whether to do live vs offline migration.I didn't really understand this. Isn't live vs. offline mutually exclusive?Yes, they're exclusive - you either live migrate, or your offline migrate. I just meant we need some way to express this in the API - or do we just go for always live migrating. I wouldn't have a problem with only doing live 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?
Rich. -- Emerging Technologies, Red Hat - http://et.redhat.com/~rjones/ Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SL4 1TE, United Kingdom. Registered in England and Wales under Company Registration No. 03798903
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature
-- Libvir-list mailing list Libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list