On Tue, Feb 28, 2023 at 04:29:22PM -0500, Michael S. Tsirkin wrote: > On Tue, Feb 28, 2023 at 02:18:25PM -0500, Stefan Hajnoczi wrote: > > On Tue, 28 Feb 2023 at 09:58, Michael S. Tsirkin <m...@redhat.com> wrote: > > > > > > On Tue, Feb 28, 2023 at 04:30:36PM +0200, Anton Kuchin wrote: > > > > I really don't understand why and what do you want to check on > > > > destination. > > > > > > Yes I understand your patch controls source. Let me try to rephrase > > > why I think it's better on destination. > > > Here's my understanding > > > - With vhost-user-fs state lives inside an external daemon. > > > A- If after load you connect to the same daemon you can get migration > > > mostly > > > for free. > > > B- If you connect to a different daemon then that daemon will need > > > to pass information from original one. > > > > > > Is this a fair summary? > > > > > > Current solution is to set flag on the source meaning "I have an > > > orchestration tool that will make sure that either A or B is correct". > > > > > > However both A and B can only be known when destination is known. > > > Especially as long as what we are really trying to do is just allow qemu > > > restarts, Checking the flag on load will thus achive it in a cleaner > > > way, in that orchestration tool can reasonably keep the flag > > > clear normally and only set it if restarting qemu locally. > > > > > > > > > By comparison, with your approach orchestration tool will have > > > to either always set the flag (risky since then we lose the > > > extra check that we coded) or keep it clear and set before migration > > > (complex). > > > > > > I hope I explained what and why I want to check. > > > > > > I am far from a vhost-user-fs expert so maybe I am wrong but > > > I wanted to make sure I got the point across even if other > > > disagree. > > > > How do the source QEMU and virtiofsd know which migration mode to use? > > The virtiofsd implementation might support both external and internal > > migration. Source QEMU needs to know whether to ask source virtiofsd > > for device state so it can be included in the migration stream or not. > > > > Stefan > > Well internal migration does not exist yet. So it is simple. > When it does maybe then we worry about how to support it? > When it does will there be a reason to do external one at all? > Why? We do internal for everything else after all. > > Or maybe we tie it to machine property? We'll know more when > it actually exists, if it ever does.
Or maybe there's a way to ask virtiofsd what does it support: it has to be supported on both source and destination. In short - we don't know, let's engineer for what we know and not guess. > > -- > MST
