OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

virtio-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [virtio-dev] [PATCH v5 1/2] content: add virtio file system device


On Tue, Aug 13, 2019 at 07:24:45AM -0400, Michael S. Tsirkin wrote:
> On Tue, Aug 13, 2019 at 10:07:11AM +0100, Stefan Hajnoczi wrote:
> > On Sat, Aug 03, 2019 at 05:12:15PM -0400, Michael S. Tsirkin wrote:
> > > On Fri, Jul 26, 2019 at 10:53:37AM +0100, Stefan Hajnoczi wrote:
> > > > +\subsubsection{Live migration considerations}\label{sec:Device Types / File System Device / Live Migration Considerations}
> > > > +
> > > > +When a guest is migrated to a new host
> > > 
> > > Please use driver and device here and elsewhere.
> > 
> > Will fix.
> > 
> > > > it is necessary to consider the FUSE
> > > > +session and its state.  The continuity of FUSE inode numbers (also known as
> > > > +nodeids) and fh values is necessary so the driver can continue operation
> > > > +without disruption.
> > > > +
> > > > +It is possible to maintain the FUSE session across live migration either by
> > > > +transferring the state or by redirecting requests from the new host to the old
> > > > +host where the state resides.  The details of how to achieve this are
> > > > +implementation-dependent and are not visible at the device interface level.
> > > > +
> > > > +Maintaining version and feature information negotiated by FUSE\_INIT is
> > > > +necessary so that no FUSE protocol feature changes are visible to the driver
> > > > +across live migration.  The FUSE\_INIT information forms part of the FUSE
> > > > +session state that needs to be transferred during live migration.
> > > 
> > > It bothers me that it's implicit, and is not exposed easily at the
> > > virtio level, so one has to bind a virtqueue and run buffers over it to
> > > even just check whether a given device supports a specific interface and
> > > can be migrated to.
> > > 
> > > How about exposing the version of the device in the config space?
> > > Spec can require that it matches the contents of the INIT command.
> > 
> > FUSE_INIT works like this:
> > 
> > 1. The client sends FUSE_INIT with the supported highest protocol
> >    version.
> > 2. If the server supports the client's version, it replies with the same
> >    version number and fills in the FUSE_INIT parameters.
> > 
> >    Otherwise the server lowers the version number and replies to the
> >    client, and the client will resend FUSE_INIT with the lower version
> >    number to acknowledge that it supports the lower version.  Go to step
> >    1.
> > 
> > With regards to live migration the server's FUSE_INIT reply structure
> > needs to be sent to the destination if a FUSE session has been
> > established.  If the destination does not support this protocol version
> > then live migration fails.
> > 
> > If management tools want to ensure that migration always succeeds then I
> > think the way to do that is not via virtio config space (they would
> > still need to start a guest in order to access it!).
> > 
> > I don't understand the benefit of exposing the device's version in the
> > config space?  Do you mean the negotiated version of the current FUSE
> > session or the highest FUSE protocol version supported by the device?
> 
> The highest version.
> The point is to make it crystal clear that for cross version migration
> the highest version must be consistent.
> Otherwise this is something implementers might easily overlook.

For migration the current FUSE session's negotiated version must be
supported by the destination.  That's all.  The highest version
supported by the device doesn't matter.

> Another option is to add non-normative text explaining what must
> be kept consistent to allow migration between devices.
> 
> Generally I think that it is unfortunate that pass-through
> devices like this one are growing extensions for
> feature negotiation outside the spec.
> This hurts attempts at generic transport pass-through like vhost-user.

I'm not sure how we'll implement vhost-user live migration.  Currently
the vhost-user protocol doesn't allow the slave to provide migration
state.  But we'll need to do this in order to transfer all the state
associated with the virtio-fs device (FUSE_INIT struct, inodes, file
locks, etc).  It's important to recognize that this state goes way
beyond the FUSE_INIT struct, there is a lot of implementation-specific
state associated with a FUSE session!

Stefan

Attachment: signature.asc
Description: PGP signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]