I'm having a problem with git cloning using http and https in a MacOS Sierra guest with Fusion 8.5 on a Mac OSX El Capitan host.
I have configured VM networking many times, and this Sierra guest is using the "Shared with my Mac" interface (NAT).
What I see is that the git clone operation starts successfully and the "%" value climbs as it receives objects, but then hangs while Receiving Objects.
Eventually, "git clone" will time out with:
error: RPC failed; curl 56 SSLRead() return error -98066 MiB/s
fatal: The remote end hung up unexpectedly
fatal: early EOF
fatal: index-pack failed
On occasion (maybe 5% of the time) it will succeed, but 95% of the time it will hang at some % value of "Receiving objects".
Are there known issues with NAT networking that could be causing this? My other MacOS VMs do not exhibit this behavior.
Same issue here. Any luck figuring it out?
I see this issue coming up all over the place (I saw a few more but can't seem to find them now):
Very interesting... I've raised the issue with our engineering team.
Does anyone on the thread have an open Support Case on this issue?
I opened one this morning. No response yet.
Edit:
Request # 17340097701
I had this problem today in a freebsd guest. Switching to bridged networking works around it for me.
-dre
I've been experiencing this problem since Fusion 8.1.0. I work with macOS VMs that frequently stall on large HTTP(S) downloads and Git clones over HTTPS. The criteria seem to be, for me:
- Using a NAT-configured virtual NIC
- "Fast enough" downstream bandwidth available (probably at least 5MBps down)
- "Large enough" file that the connection has at least a few seconds to pull data down without the transfer being complete
The numbers aren't identical each time, but it does not take many attempts to trigger the error. I've experienced this both on a large (fast) University network connection and on MacMiniColo-hosted Mac Minis. In all cases these are VMs running OS X 10.11.6, but it would seem from this thread that FreeBSD guests may exhibit the same issue. Numerous others have confirmed the same findings and most people tend to switch to bridged networking to avoid the issue. Unfortunately that's not a possible network configuration in some of the environments I work in.
Here's a video demonstrating how trivial it is to trigger the bug, wherein I attempt to download the Office 2016 installer, which is over 1GB in size:
https://dl.dropboxusercontent.com/u/429559/VMware%20Fusion%20NAT%20bug.mp4
You can see that around 2:40, I've done 4 downloads of the same ~1GB installer of the 2016 Office for Mac installer, 3 out which have stalled indefinitely.
A workaround I've been using for a while is to use a current VMware Fusion app but drop-in replace the vmnet-natd binary with the version from 8.0.2, or to use this one that's available for download (which was distributed by VMware to resolve the 8.1.x NAT port forwarding issue):
https://www.vmware.com/go/dl_vmnet-natd
Tim
I received a reply to my support request. They were able to reproduce the issue and said that the fix will be included in the next release!
I have a similar issue which I believe to be the same. See this post with detailed reproducibility results as well as an in-depth breakdown of the symptom: macOS 10.12 guest socket timeout with TCP window reduced to 0
VMware Fusion 8.5.7 has been released, and contains a fix for this issue. VMware Fusion 8.5.7 Release Notes
Please let us know if you continue to encounter difficulties after installing the update.
Cheers,
--
Darius