[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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,
        hostname ? hostname : nchostname,

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


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

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]