VMware Communities
jdubnm
Contributor
Contributor

Fusion 8.5 with MacOS Sierra guest: git clone failing in guest

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.

9 Replies
joezeroc
Contributor
Contributor

Same issue here. Any luck figuring it out?

Reply
0 Kudos
joezeroc
Contributor
Contributor

Reply
0 Kudos
Mikero
Community Manager
Community Manager

Very interesting... I've raised the issue with our engineering team.

Does anyone on the thread have an open Support Case on this issue?

-
Michael Roy - Product Marketing Engineer: VCF
Reply
0 Kudos
joezeroc
Contributor
Contributor

I opened one this morning. No response yet.

Edit:

Request # 17340097701

Reply
0 Kudos
dreness
Contributor
Contributor

I had this problem today in a freebsd guest. Switching to bridged networking works around it for me.

-dre

Reply
0 Kudos
timothysutton
Contributor
Contributor

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

Reply
0 Kudos
joezeroc
Contributor
Contributor

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!

Reply
0 Kudos
pkcxbr
Contributor
Contributor

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

Reply
0 Kudos
dariusd
VMware Employee
VMware Employee

VMware Fusion 8.5.7 has been released, and contains a fix for this issue.  VMware Fusion 8.5.7 Release Notes

Download VMware Fusion 8

Please let us know if you continue to encounter difficulties after installing the update.

Cheers,

--

Darius

Reply
0 Kudos