On Fri, Aug 04 2017, Stefan Hajnoczi wrote: > 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. I've already addressed this issue. I wrote: True, the admin might delete the link-local address themselves. They might also delete /sbin/mount.nfs. Maybe they could even "rm -rf /". A rogue admin can always shoot themselves in the foot. Trying to prevent this is pointless. > > 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. I suggest you look up the proverb about making things fool-proof and learn to apply it. Meanwhile I have another issue. Is it possible for tcpdump, or some other tool, to capture all the packets flowing over a vsock? If it isn't possible to analyse the traffic with wireshark, it will be much harder to diagnose issues that customers have. NeilBrown > > Stefan
Attachment:
signature.asc
Description: PGP signature
