On Thu, Jul 15, 2010 at 5:22 PM, Iustin Pop <[email protected]> wrote: > On Thu, Jul 15, 2010 at 18:18, Guido Trotter <[email protected]> wrote: >> On Thu, Jul 15, 2010 at 5:09 PM, Iustin Pop <[email protected]> wrote: >>> Since migration live/non-live is more stable (e.g.) for Xen-PVM versus >>> Xen-HVM, we introduce a new parameter for what mode we should use by >>> default (if not overridden by the user, in the opcode). >>> >>> The meaning of the opcode 'live' field changes from boolean to either >>> None (use the hypervisor default), or one of the allowed migration >>> string constants. The live parameter of the TLMigrateInstance is still a >>> boolean, computed from the opcode field (which is no longer passed to >>> the TL). >> >> LGTM >> >> Just wondering: >> >>> + if self.lu.op.live is None: >>> + # read the default value from the hypervisor >>> + i_hv = self.cfg.GetClusterInfo().FillHV(instance, skip_globals=False) >>> + self.lu.op.live = i_hv[constants.HV_MIGRATION_TYPE] >>> + >> >> Does it make sense to calculate this here, or should we just leave it >> to the hypervisor code (and just pass on the overriding value, if we >> got any?). > > It would mean to be replicated in a couple of places (via a common > function, of course), and today it doesn't give us any advantage over > plain boolean. If the modes would mean different things for various > hypervisors, or if e.g. lxc would have a different mode (snapshot), > then yes.
True as well. But then we have a new place where we fill/calculate the hv params, while the hypervisors already do that. Thanks, Guido
