Re: [PATCH v3 1/1] vhost-user-fs: add migration type property

["Michael S. Tsirkin" <mst@redhat.com>]

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 <mst@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