On 02/10/2018 10:29, Jan Beulich wrote: >>>> On 01.10.18 at 18:07, <jgr...@suse.com> wrote: >> On 01/10/2018 17:48, George Dunlap wrote: >>> On 10/01/2018 04:40 PM, Andrew Cooper wrote: >>>> If there isn't an obvious fix, then the switch of default scheduler >>>> needs reverting until there is a fix present. This is currently >>>> blocking master. >>> >>> Agreed. I'd argue for ignoring failures to set scheduler parameters on >>> migrate, on the grounds that this will be less risk to the project as a >>> whole than reverting credit2 again. But either way we should do >>> something quickly. >> >> We should ignore a mismatch of the scheduler. Failures when setting >> parameters for a matching scheduler should not be ignored IMO. > > Well, depends on whether the scheduler was explicitly chosen. > I don't think migration should succeed when e.g. RTDS was used > and isn't available on the destination host.
The only way I could think of to tell an explicit vs. an implicit scheduler selection would be to specify a cpupool in the domain's config file. So what about the following: A mismatch of the scheduler should be ignored on the receiving side if no cpupool was specified explicitly for the domain. I have checked that config.c_info.pool_name in JSON data is available only if the cpupool is specified in the domain config. Juergen _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
