Some questions (to be added to README perhaps)

[elmarco]

Hi,

Why do you use virtio-vsock and not let the guest use regular virtio-net?

Except the license, and vsock usage, what are the differences with https://github.com/majek/slirpnetstack?

thanks

[guillaumerose]

Hi,

I use vsock because this is the common interface that is offered by both Linux, macOS (with Hyperkit) and Windows (with Hyper-V). Yes for Linux, we can do better but for others OSes we can't as far as I know. This solution is known to work well. https://github.com/moby/vpnkit/ which powered Docker Desktop, is exactly doing that. It's just far more easier to maintain Go code than OCaml, esp. if the network stack is maintained by Google.

slirpnetstack uses exactly the same mechanism to forward connections from/to the host (it's almost just a matter of configuration of gvisor). Only the plumbing is different: slirpnetstack is for containers, this project is for VMs. gvisor-tap-vsock adds the ability to connect multiples clients and acts as a real switch. It will also include a custom DNS tailored for crc and a way to dynamically expose ports on the host.

Guillaume

[elmarco]

If you do ethernet/IP, virtio-net should be available on all OS we care about. I don't understand what you need vsock for.

slirpnetstack can be made to work with a VM with a TAP fd (-fd option).

I used to work on slirpnetstack to replace slirp-helper (or slirp4netns used by podman, both using libslirp)

(I lost interest, as I don't believe in the long term on a userspace network stack. There is way too much things to take care of, performance and features will always suffer and lag. We should rely on the kernel to do it. Today, it requires some privileges, depending on the solution, but hopefully some day we will find a way to restrict RAW sockets for example.. or reuse the host network stack somehow)

[guillaumerose]

For instance, slirpnetstack doesn't compile on Windows because it uses rawfile access (https://github.com/google/gvisor/tree/master/pkg/tcpip/link/rawfile).

This purpose of this project is:

• to help users access VPN with CRC on Windows
• have a better control of the network esp. on Windows

Having it working on Linux is good but it's optional.

[gbraad]

Are there still open questions here and/or suggestions of what to add to the README?

[elmarco]

Are there still open questions here and/or suggestions of what to add to the README?

My understanding is that the project largely overlap with slirpnetstack, except it has better support for Windows today.

Fwiw, packaging such project in various distros is a real pain. netstack is no longer a separate project, and gvisor is only support on x64 so far, iirc. Furthermore, Google engineers don't care much about netstack contributions. So I wish you good luck with this yet-another-slirp project! :)

[gbraad]

we only support x64 anyway

I am not sure what the actual aim of this issue is now. You request clarification and additions to the README, but in fact I see sarcastic remarks about the possible support for gvisor? Understand why we use this implementation. vsock provides a way to communicate from the hypervisor with the host, and allows us to easily retarget the ports and traffic for the host<->vm traffic. Can you clarify what the actual problem here is?

On Fri, Sep 18, 2020 at 8:06 PM Marc-Andre Lureau notifications@github.com wrote:

Are there still open questions here and/or suggestions of what to add to the README?

My understanding is that the project largely overlap with slirpnetstack, except it has better support for Windows today.

Fwiw, packaging such project in various distros is a real pain. netstack is no longer a separate project, and gvisor is only support on x64 so far, iirc. Furthermore, Google engineers don't care much about netstack contributions. So I wish you good luck with this yet-another-slirp project! :)

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/code-ready/gvisor-tap-vsock/issues/3#issuecomment-694829413, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAAOZTQKLQC4OQBKGFZRV3SGNEMRANCNFSM4RNHTDBA .

--

Gerard Braad | http://gbraad.nl

STEM is the source, but BUILD is how you develop! [ Better Understanding Involves Learning and Doing ]

[elmarco]

we only support x64 anyway

Fair enough. But very quickly, such low-level project requires more portability.

I am not sure what the actual aim of this issue is now. You request clarification and additions to the README, but in fact I see sarcastic remarks about the possible support for gvisor? Understand why we use this implementation. vsock provides a way to communicate from the hypervisor with the host, and allows us to easily retarget the ports and traffic for the host<->vm traffic. Can you clarify what the actual problem here is?

How do you redirect guest TCP/IP traffic over vsock? Or you don't, and the guest has some special socket handling?

Sorry, it's more scepticism actually - but you know FUD, do what you believe is right and prove that you are!

thanks

[gbraad]

How do you redirect guest TCP/IP traffic over vsock?

The guest can have all 'native hypervisor' adapters ignored and rely on just the vsock. The vsock implementation gets bound to a TAP device inside the guest that runs the vm command:

https://github.com/code-ready/gvisor-tap-vsock/blob/eb8add84d1e89f7a46f1dd7b3fdc073a6ee6fc12/cmd/vm/main.go#L77-L82

Note: water is just a TAP handling library for Go.

After the creation, two functions exist that handle the multiplexing:

https://github.com/code-ready/gvisor-tap-vsock/blob/eb8add84d1e89f7a46f1dd7b3fdc073a6ee6fc12/cmd/vm/main.go#L89-L90

called rx and tx. The receiving daemon is called host that handles the (de)multiplexing on the host side.

The TAP device gets an IP address assigned and the route table gets modified to include a default gateway, etc. This process is described in the README.

[elmarco]

Ok, why do that extra TAP<->vsock when you can simply use the hypervisor adapter? If virtio-vsock is available, I suppose virtio-net is as well? Or is it another vsock device?

[gbraad]

On Windows the behaviour for the hypervisor device is different as it will have to use DHCP+NAT provided by the virtual networking stack; by means of the Default Switch and ICS.

[elmarco]

Does that mean that on windows, with hyperv, you can't handle the traffic manually of a network adapter? There is no private network?

[gbraad]

There is, but you would have to provide your own DHCP and NAT (as only a single NAT implemementation can exist from the networking stack; and often already cliamed). We can NOT rely on a pre-assigned IP address. We did for Minishift but needs modifcations to the image and inclusion of an additional daemon process to communciate with the hypervisor).

[elmarco]

I failed to understand the requirement for a DHCP (server?). You should be able to configure the guest in different ways.

Isn't slirp/gvisor-tap-vsock doing a kind of NAT anyway?

[gbraad]

The VM, like with RH CoreOS is configured using DHCP. No changes to the image are made to remain as close (unmodified) to the actual production-like deployment method.

However, this all deviates from the original request: "Why do you use virtio-vsock and not let the guest use regular virtio-net?". We do not see a need to use a different library or implementation. We are more concerned about a working implementation for all the different platforms involved. Since no clear motivation about the difference or reference implementation is given, I'll close this issue.

If more information about the current implementation with vsock is needed, please consider jumping onto IRC or find us on slack.