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

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?

Attachment: signature.asc
Description: PGP signature

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