Re: [PATCH nfs-utils v3 00/14] add NFS over AF_VSOCK support

["bfields@fieldses.org" <bfields@fieldses.org>]

On Wed, Sep 20, 2017 at 06:17:07PM +0000, Trond Myklebust wrote:
> On Wed, 2017-09-20 at 08:25 -0700, Frank Filz wrote:
> > > > On Sep 20, 2017, at 10:45 AM, J. Bruce Fields <bfields@fieldses.o
> > > > rg>
> > 
> > wrote:
> > > > 
> > > > On Wed, Sep 20, 2017 at 10:40:45AM -0400, Chuck Lever wrote:
> > > > > File handles suddenly change and lock state vanishes after a
> > > > > live
> > > > > migration event, both of which would be catastrophic for
> > > > > hypervisor
> > > > > mount points.
> > > > 
> > > > They're talking about a Ganesha/Ceph backend.  It should be able
> > > > to
> > > > preserve filehandles.
> > > 
> > > That's only one possible implementation. I'm thinking in terms of
> > > what
> > 
> > needs
> > > to be documented for interoperability purposes.
> > 
> > It seems like live migration pretty much requires a back end that
> > will
> > preserve file handles.
> > 
> > > > Lock migration will require server-side implementation work but
> > > > not
> > > > protocol changes that I'm aware of.
> > > > 
> > > > It could be a lot of implementation work, though.
> > > 
> > > Agreed.
> > 
> > I think the lock migration can be handled the way we handle state
> > migration
> > in an HA environment - where we treat it as a server reboot to the
> > client
> > (so SM_NOTIFY to v3 clients, the various errors v4 uses to signal
> > server
> > reboot, in either case, the client will initiate lock reclaim).
> > 
> 
> Mind showing us an architecture for that? As far as I can see, the
> layering is as follows:
> 
> VM client
> --------------
> host knfsd
> --------------
> host client
> --------------
> Storage server
> 
> So how would you notify the VM client that its locks have been
> migrated?

All I've seen mentioned in this thread is

  VM client
  ---------
  host Ganesha
  ---------
  Ceph or Gluster

Did I misunderstand?

NFS proxying would certainly make it all more entertaining.

--b.