[libvirt] [PATCH 2/2] add default migrate uri in definition file

[Jiri Denemark]

On Wed, Apr 16, 2014 at 10:12:18 +0000, chen.fan.fnst at cn.fujitsu.com wrote:
> On Wed, 2014-04-16 at 10:08 +0100, Daniel P. Berrange wrote: 
> > On Wed, Apr 16, 2014 at 04:19:05AM +0000, chen.fan.fnst at cn.fujitsu.com wrote:
> > > Hi Daniel,
> > > 
> > > On Tue, 2014-04-15 at 12:04 +0100, Daniel P. Berrange wrote: 
> > > > On Tue, Apr 15, 2014 at 06:31:09PM +0800, Chen Fan wrote:
> > > > > Current virsh migrate command require specfying migration URI with
> > > > > command option.
> > > > > 
> > > > > Here is current step.
> > > > > 1) If user specifies --migrateuri on virsh migrate command, then the command
> > > > >    transfers the data to specified host.
> > > > > 2) If --migrateuri is not specified, the command transfers the data to host
> > > > >    whose name is resolved by DNS or /etc/hosts.
> > > > > 
> > > > >    but we are able to use virsh migrate command more usefull.
> > > > >    User can specify a constant destination by definition file.
> > > > >    if user want to specify other temporary destination, command option
> > > > >    is good for it.
> > 
> > 
> > > > 
> > > > IMHO the idea of storing the 'migration_uri' parameter in a configuration
> > > > file is just plain wrong. This value is inherantly associated with the
> > > > host that you're migrating to. So if you set 'migration_uri' to one host
> > > > in the config, but then invoke virDomainMigrate with a virConnectPtr that
> > > > is associated with a different host, this just crashes and burns. 
> > > 
> > > how about add a optional 'migrate_uri'(or 'data_migrate_uri') in
> > > libvirtd.conf as secondary network interface?
> > > if so, when user add a new NIC in host A, then user can store this NIC
> > > address to 'migrate_uri' parameter in the configuration file, then when 
> > > doing migration from other host B to this host A, we can get the
> > > 'migrate_uri' address in host A and pass this uri back to host B as the
> > > new 'uri_out' value at domainMigratePrepare3Params(). then we don't need
> > > to change any existing APIs. and the new NIC used to transfer migrate
> > > data will be more useful.
> > 
> > The problem is that the migrate_uri is tied to a specific target host,
> > while the API can be told to migrate to any host. I just dont see how
> > it makes sense to store this URI in any configuration file.
> > 
> 
> I'm sorry if I confused you.
> My new Idea is that:
>    If we have 2 NIC or more in our target host, we can configure the
> secondary NIC address as the migrate data transfer's address on this
> host, then when other hosts need to migrate VM to this target host,
> they could through the dest_uri to get this secondary address from the
> target host. thus the secondary NIC can be used to transfer migrate
> data. certainly, the default configuration should be disabled. and this
> uri just was tied to its host. if the API want to migrate to any host,
> it should be not affected I guess. :)

During migration destination libvirtd sends the URI which it thinks is
the one that can be used to contact the daemon from other hosts.
Currently we construct the URI from hostname and IIUC this request is to
make it configurable. In other words, instead of using the hostname,
libvirtd would use the address specified in the configuration file. That
is, an admin would be able to explicitly configure which of the host's
addresses should be used for incoming migrations unless overridden by
migrate URI passed to the Prepare migration API.

Am I correct? If so, I believe this can be useful.

Jirka