-
Notifications
You must be signed in to change notification settings - Fork 589
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Network connectivity is quite flaky with some parallel outgoing connections #561
Comments
You can try if using VDE helps ? https://github.com/lima-vm/vde_vmnet It seems that slirp is worse on Mac. |
I had similar issues (but not quite) with podman machine too. I suppose it might be even qemu issue of some kind. I'll try the vmnet, it looked bit unnecessary (as all I need is really just container -> outer world connectivity) but if it works better.. |
Hmm, podman machine uses gvproxy But maybe slirp still, for internet DNS ? |
gvproxy seems to perform much worse in terms of speed (that's why I switched to lima to start with); the weird part is that it is most likely not (only) DNS, it seems that the result is 'network unreachable' from TCP connect(). |
Seems to work better with the vde.. initially it didn't though, as the slirp was preferred default route still:
Needed to run following:
The configuration I had was:
|
Maybe VDE should be packaged for Linux as well ? https://wiki.alienbase.nl/doku.php?id=slackware:vde There is the root requirement, but maybe if it can be narrowed down to a couple of sudo or suid perhaps. |
No, because For Linux we should support TAP with |
I meant VDE (not vde_vmnet), but I think it's the same TUN/TAP. But it would be more for performance, not as much for stability. |
Much to my surprise VDE is quite slow; in my testing it was 7 times slower than the slirp user mode networking in qemu. And that was after fixing a bug in the vde_bridge code; before it was almost 350 times slower. Timings in virtualsquare/vde-2#35. So it might be better to do TUN/TAP directly without going through VDE, but just a guess until we benchmark... |
Trying to remember what libvirt uses, just know it gets two Which in turn is mostly legacy from the VirtualBox setup, NAT + Host-Only. EDIT:
Note: libvirt requires root, so it can set up all kind of virtual bridges on the host |
Very non-scientific benchmark but yeah, the VDE perf is pretty bad (most recent master built for the vde*): slirp:
vde:
(Both of these are to the host machine, so no real network was harmed during the test) |
I only get the desired behaviour on Lima with nerdctl running on user-level, even though the host has same issue. Every other permutations of the following attempts has also reproduced the behaviour.
I do notice the difference in nameservers on user and system level nerdctl.
|
I don't actually know how containerd configures DNS (inside k3s it uses coredns; not sure how it works for user mode containerd). The entries for system mode containerd look suspicious:
Either way, you (we) should not have both nameservers in there, as they are no equivalent. Multiple nameservers in FWIW, I only get the single expected nameserver when using system mode containerd: jan@lima-default:~$ sudo nerdctl run --rm -it alpine -- cat /etc/resolv.conf
nameserver 192.168.5.3 |
Sorry for the confusion, that is with vmnet shared network enabled. Without that, it is same as yours. |
I see, thanks! That will be a potential source of problems: jan@lima-default:~$ sudo nerdctl run --rm -it alpine -- cat /etc/resolv.conf
search home
nameserver 192.168.5.3
nameserver 192.168.105.1
jan@lima-default:~$ resolvectl status
Global
Protocols: -LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
resolv.conf mode: stub
Link 2 (eth0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.5.3
DNS Servers: 192.168.5.3
Link 3 (lima0)
Current Scopes: DNS
Protocols: +DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported
Current DNS Server: 192.168.105.1
DNS Servers: 192.168.105.1
DNS Domain: home
Link 4 (nerdctl0)
Current Scopes: none
Protocols: -DefaultRoute +LLMNR -mDNS -DNSOverTLS DNSSEC=no/unsupported It does pick up a search domain from the host, but the simplistic The jan@lima-default:~$ cat /etc/resolv.conf
[...]
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
[...]
nameserver 127.0.0.53
options edns0 trust-ad
search home Again, I don't know how But you said you get the flaky networking even without the additional vde_vmnet network (and DNS), so it should be immaterial for this issue. |
I do not know whether I should append in this issue , but in my case it do nothing with the DNS resolver , even with the pure IP:Port, the network issue seems existed . In my case , I use After I install the |
I used raw qemu before and tested several options for networking. I found that vde is really slow compared to user-mode networking. I though we could attach two interfaces to vm: the user-mode device for out traffic and a vde for a connection between vms(if needed). |
I tried out PTP mode and it seems to be more stable for situations like #561 (comment). The download speed is okay and there is also a report of a better dns performance (when used for dns). But there are still two main issues.
It looks like the safest best is still your recommendation i.e. to limit vde to providing reachable address to the vm and retaining the user-mode for normal traffic. |
Hi all - is this the root cause for the Slirp issues: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/35 ? |
that looks like it |
Seems already fixed in libslirp v4.5.0 (18 May, 2021): https://gitlab.freedesktop.org/slirp/libslirp/-/merge_requests/73 |
I saw that, however the issue described is near identical to the current issue as well. |
This particular one was fixed, but follow-up problem surfaced in 0.12 ( see #1285 ). Closing this though. |
lima 0.8.1, default networking setup:
When running something that makes bunch of connections (per second) in other window, e.g. fetching www.google.com fails or is quite slow. In practise, lots of apps report network unreachable. It is not matter of bandwidth (the connections do not do much). Switching DNS to
useHostResolver: false
did not help.The text was updated successfully, but these errors were encountered: