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). Guest administrators are confronted with a new interface - this opens up the possibility that they change its configuration. 2. Default drop firewall policies conflict with the interface. The guest administrator would have to manually configure exceptions for their firewall. 3. udev is a Linux-only solution and other OSes do not offer a configurable interface naming scheme. Manual configuration would be required. 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. 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
