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

Richard W.M. Jones rjones at redhat.com
Mon Jul 16 17:52:15 UTC 2007


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.

>>> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3237 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://listman.redhat.com/archives/libvir-list/attachments/20070716/5acb3fa7/attachment-0001.bin>


More information about the libvir-list mailing list