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

chen.fan.fnst at cn.fujitsu.com chen.fan.fnst at cn.fujitsu.com
Thu Apr 17 00:47:55 UTC 2014


On Wed, 2014-04-16 at 13:42 +0200, Jiri Denemark wrote: 
> 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.
Yes, your understanding is correct.
Thanks for your generous explanation.

I would like to make patches to implement it subsequently.

Thanks,
Chen

> 
> Jirka





More information about the libvir-list mailing list