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@xxxxxxxxxxxxxx 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@xxxxxxxxxxxxxx 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 -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list