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

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(a)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. :)