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

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

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.


-- 
MST