On Fri, Aug 04, 2017 at 07:45:22AM +1000, NeilBrown wrote: > On Thu, Aug 03 2017, Stefan Hajnoczi wrote: > > On Fri, Jul 28, 2017 at 09:11:22AM +1000, NeilBrown wrote: > >> On Thu, Jul 27 2017, Stefan Hajnoczi wrote: > >> > On Thu, Jul 27, 2017 at 03:13:53PM +1000, NeilBrown wrote: > >> >> On Tue, Jul 25 2017, Stefan Hajnoczi wrote: > >> >> > On Fri, Jul 07, 2017 at 02:13:38PM +1000, NeilBrown wrote: > >> >> >> On Fri, Jul 07 2017, NeilBrown wrote: > >> >> >> > On Fri, Jun 30 2017, Chuck Lever wrote: > > I still see these as blockers preventing guest<->host file system > > sharing. Users can already manually add a NIC and configure NFS today, > > but the goal here is to offer this as a feature that works in an > > automated way (useful both for GUI-style virtual machine management and > > for OpenStack clouds where guest configuration must be simple and > > scale). > > > > In contrast, AF_VSOCK works as long as the driver is loaded. There is > > no configuration. > > I think we all agree that providing something that "just works" is a > worth goal. In only question is about how much new code can be > justified, and where it should be put. > > Given that almost everything you need already exists, it seems best to > just tie those pieces together. Neil, You said downthread you're losing interest but there's a point that I hope you have time to consider because it's key: Even if the NFS transport can be set up automatically without conflicting with the user's system configuration, it needs to stay available going forward. A network interface is prone to user configuration changes through network management tools, firewalls, and other utilities. The risk of it breakage is significant. That's not really a technical problem - it will be caused by some user action - but using the existing Linux AF_VSOCK feature that whole class of issues can be eliminated. Stefan
Attachment:
signature.asc
Description: PGP signature
