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: >> >> To achieve zero-config, I think link-local addresses are by far the best >> >> answer. To achieve isolation, some targeted filtering seems like the >> >> best approach. >> >> >> >> If you really want traffic between guest and host to go over a vsock, >> >> then some sort of packet redirection should be possible. >> > >> > The issue we seem to hit with designs using AF_INET and network >> > interfaces is that they cannot meet the "it must avoid invasive >> > configuration changes, especially inside the guest" requirement. It's >> > very hard to autoconfigure in a way that doesn't conflict with the >> > user's network configuration inside the guest. >> > >> > One thought about solving the interface naming problem: if the dedicated >> > NIC uses a well-known OUI dedicated for this purpose then udev could >> > assign a persistent name (e.g. "virtguestif"). This gets us one step >> > closer to non-invasive automatic configuration. >> >> I think this is well worth pursuing. As you say, an OUI allows the >> guest to reliably detect the right interface to use a link-local address >> on. > > IPv6 link-local addressing with a well-known MAC address range solves > address collisions. The presence of a network interface still has the > following issues: > > 1. Network management tools (e.g. NetworkManager) inside the guest > detect the interface and may auto-configure it (e.g. DHCP). Why would this matter? Auto-configuring may add addresses to the interface, but will not remove the link-local address. > Guest > administrators are confronted with a new interface - this opens up > the possibility that they change its configuration. 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. > > 2. Default drop firewall policies conflict with the interface. The > guest administrator would have to manually configure exceptions for > their firewall. This gets back to my original point. You are willing to stick required-configuration in the kernel and in nfs-utils, but you are not willing to require some fixed configuration which actually addresses your problem. If you want an easy way to punch a firewall hole for a particular port on a particular interface, then resolve that by talking with people who understand firewalls. Not by creating a new protocol which cannot be firewalled. > > 3. udev is a Linux-only solution and other OSes do not offer a > configurable interface naming scheme. Manual configuration would > be required. Not my problem. If some other OS is lacking important functionality, you do fix it by adding rubbish to Linux. You fix it by fixing those OSes. For example, is Linux didn't have udev or anything like it, I might be open to enhancing mount.nfs so that an address syntax like: fe80::1%*:xx:yy:xx:* would mean the that glob pattern should be matched again the MAC address of each interface and the first such interface used. This would be a focused change addressed at fixing a specific issue. I might not actually like it, but if it was the best/simplest mechanism to achieve the goal, I doubt I would fight it. Fortunately I don't need decide as we already have udev. If some of OS doesn't have a way to find the interface for a particular MAC address, maybe you need to create one. > > 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. NeilBrown > > The changes required to Linux and nfs-utils are related to the sunrpc > transport and configuration. They do not introduce risks to core NFS or > TCP/IP. I would really like to get patches merged because I currently > have to direct interested users to building Linux and nfs-utils from > source to try this out. > > Stefan
Attachment:
signature.asc
Description: PGP signature
