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 don't think the server can filter connections based on which interface > >> a link-local address came from. If that was a problem that someone > >> wanted to be fixed, I'm sure we can fix it. > >> > >> If you need to be sure that clients don't fake their IPv6 address, I'm > >> sure netfilter is up to the task. > > > > Yes, it's common to prevent spoofing on the host using netfilter and I > > think it wouldn't be a problem. > > > >> . Creates network interfaces on host that must be managed > >> > >> What vsock does is effectively create a hidden interface on the host that only the > >> kernel knows about and so the sysadmin cannot break it. The only > >> difference between this and an explicit interface on the host is that > >> the latter requires a competent sysadmin. > >> > >> If you have other reasons for preferring the use of vsock for NFS, I'd be > >> happy to hear them. So far I'm not convinced. > > > > Before working on AF_VSOCK I originally proposed adding dedicated > > network interfaces to guests, similar to what you've suggested, but > > there was resistance for additional reasons that weren't covered in the > > presentation: > > I would like to suggest that this is critical information for > understanding the design rationale for AF_VSOCK and should be easily > found from http://wiki.qemu.org/Features/VirtioVsock Thanks, I have updated the wiki. > 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. Stefan
Attachment:
signature.asc
Description: PGP signature
