On 10/01/2018 06:58 PM, Dario Faggioli wrote: > On Mon, 2018-10-01 at 18:07 +0200, Juergen Gross wrote: >> On 01/10/2018 17:48, George Dunlap wrote: >>> On 10/01/2018 04:40 PM, Andrew Cooper wrote: >>>> On 01/10/18 16:35, Wei Liu wrote: >>>>>> Wait, the migration code reads the scheduler parameters -- >>>>>> even if these >>>>>> have not been explicitly set by the admin -- and sends them >>>>>> along with >>>>>> the migration stream? And if the remote scheduler is >>>>>> different, the >>>>>> migration fails? >>>>>> >>>>>> That's not so good. :-) >>>>> >>>>> But one can argue that the guest is specific configured that >>>>> way so it's >>>>> parameters should be preserved. We normally analyse things on a >>>>> case by >>>>> case basis. >>>> >>>> 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. >> > Indeed! Especially considering that this isn't really related on what > the default scheduler is (despite it being making Credit2 default that > triggers the issue). > > In fact, what if: > - user uses Credit1 (default and supported) on host A > - user uses Credit2 (supported) on host B > - user migrates VM > - BOOOM! > > So, unless it is intended --and, I'd say, also documented somewhere-- > that migrating between hosts which use different schedulers is to be > avoided, this is already a bug, whatever the default scheduler is... > > George, let me know if you're working on a fix already, or if I should > do that myself.
I reverted the credit2 default; but really we need to have a design discussion about what we want the overall behavior to be. It's not simple or obvious. -George _______________________________________________ Xen-devel mailing list Xen-devel@lists.xenproject.org https://lists.xenproject.org/mailman/listinfo/xen-devel
