----- Original Message ----- > From: "Roy Golan" <rgolan(a)redhat.com&gt; > To: engine-devel(a)ovirt.org > Sent: Thursday, June 6, 2013 8:17:54 AM > Subject: [Engine-devel] cluster emulation mode feature > > Hi, > > A new wiki has been published on Cluster Emulation mode > http://www.ovirt.org/Cluster_emulation_modes > > Please review. > > Thanks, > Roy > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > maybe better to name host field as supported_emulated_machines - since it holds the list of supported as reported from vdsm.

the following is a copy from the wiki " consider this pseudo-code: operational = false if cluster.emulationMode == NULL for configVal in Config.ClusterEmulationMode(3.3) if configVal in host.emulationModes cluster.emulationMode = configVal operational = true else if clusterEmulationMode in host.emulationMode operational = true if (!operational) set host non operationl, reason = UNSUPPORTED_EMULATION_MODE " first, i guess where you write '3.3' its actually should be 'cluster.compatibility'

another thing, the configuration will probably have more than 1 option for emulated machine, for example 3.3 rhel could have {(for EL-)RHEL6.4.0,RHEL6.3.0,..,(for other-)pc-1.3,pc-1.2..} we need to make sure the list is used ordered so that the greatest value will be first, since if host supports many, the latest will be used. in cpu-flags there is a specific number to do this order, maybe same approach can be taken here, as i'm not sure the RHEL/pc values are consistent (on my f18 i also have 'pc-i440fx-1.4')

----- Original Message ----- > From: "Roy Golan" <rgolan(a)redhat.com&gt; > To: "Omer Frenkel" <ofrenkel(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org > Sent: Thursday, June 6, 2013 12:33:26 PM > Subject: Re: [Engine-devel] cluster emulation mode feature > > On Thu 06 Jun 2013 10:20:30 AM IDT, Omer Frenkel wrote: >> >> >> ----- Original Message ----- >>> From: "Roy Golan" <rgolan(a)redhat.com&gt; >>> To: engine-devel(a)ovirt.org >>> Sent: Thursday, June 6, 2013 8:17:54 AM >>> Subject: [Engine-devel] cluster emulation mode feature >>> >>> Hi, >>> >>> A new wiki has been published on Cluster Emulation mode >>> http://www.ovirt.org/Cluster_emulation_modes >>> >>> Please review. >>> >>> Thanks, >>> Roy >>> _______________________________________________ >>> Engine-devel mailing list >>> Engine-devel(a)ovirt.org >>> http://lists.ovirt.org/mailman/listinfo/engine-devel >>> >> >> maybe better to name host field as supported_emulated_machines - since it >> holds the list of supported as reported from vdsm. >> > will change if this seems clearer seems clearer to me.

>> the following is a copy from the wiki >> " >> consider this pseudo-code: >> >> operational = false >> if cluster.emulationMode == NULL >> for configVal in Config.ClusterEmulationMode(3.3) >> if configVal in host.emulationModes >> cluster.emulationMode = configVal >> operational = true >> else if clusterEmulationMode in host.emulationMode >> operational = true >> if (!operational) >> set host non operationl, reason = UNSUPPORTED_EMULATION_MODE >> " >> >> first, i guess where you write '3.3' its actually should be >> 'cluster.compatibility' > yes its just a visual notion of the version >> another thing, the configuration will probably have more than 1 option for >> emulated machine, >> for example 3.3 rhel could have {(for EL-)RHEL6.4.0,RHEL6.3.0,..,(for >> other-)pc-1.3,pc-1.2..} >> we need to make sure the list is used ordered so that the greatest value >> will be first, >> since if host supports many, the latest will be used. >> in cpu-flags there is a specific number to do this order, maybe same >> approach can be taken here, >> as i'm not sure the RHEL/pc values are consistent (on my f18 i also have >> 'pc-i440fx-1.4') > isn't the order of the list enough? > basically yes, it means we assume users who will change it will be aware the order matters. im ok with that because i assume not many changes will be done here (as this just the defaults)

On 06/06/2013 08:17 AM, Roy Golan wrote: > Hi, > > A new wiki has been published on Cluster Emulation mode > http://www.ovirt.org/Cluster_emulation_modes > > Please review. > > Thanks, > Roy > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel strange, I thought the EmulatedMachine config value we currently have was also used to validate host support, but seems we were missing that part.

what will happen with the current EmulatedMachine config value?

what happens when cluster emulation mode changes to hosts not matching it?

----- Original Message ----- > From: "Roy Golan" <rgolan(a)redhat.com&gt; > Cc: engine-devel(a)ovirt.org > Sent: Sunday, June 9, 2013 8:56:45 AM > Subject: Re: [Engine-devel] cluster emulation mode feature > > On 06/08/2013 10:33 PM, Itamar Heim wrote: > > On 06/06/2013 08:17 AM, Roy Golan wrote: > >> Hi, > >> > >> A new wiki has been published on Cluster Emulation mode > >> http://www.ovirt.org/Cluster_emulation_modes > >> > >> Please review. > >> > >> Thanks, > >> Roy > >> _______________________________________________ > >> Engine-devel mailing list > >> Engine-devel(a)ovirt.org > >> http://lists.ovirt.org/mailman/listinfo/engine-devel > > > > strange, I thought the EmulatedMachine config value we currently have > > was also used to validate host support, but seems we were missing that > > part. > > I was also puzzled while doing git grep -i emulatedmachine > > > > > what will happen with the current EmulatedMachine config value? > > The OVF builder will use the cluster config and EmulatedMachine will be > deleted > > > > > what happens when cluster emulation mode changes to hosts not matching > > it? > > Updating cluster's emulation mode is prohibited when active hosts has > running VMs. > if VMs are not running on them they will transit to non-op on the next > refresh > the emulated machines are reported on getCaps, not getStats, so not sure what refresh you refer to, anyway i think we should allow if no vms running but all active hosts support new value and block otherwise (if vms are running or one of the active hosts doesn't support new value) iirc this is the logic for changing cpu type

> > > > > > > _______________________________________________ > Engine-devel mailing list > Engine-devel(a)ovirt.org > http://lists.ovirt.org/mailman/listinfo/engine-devel > _______________________________________________ Engine-devel mailing list Engine-devel(a)ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-devel