Bug 9111 - MTVS: Mac build hosts not automatically detected in VMs hosted by Virtual Box and using NAT connection
Summary: MTVS: Mac build hosts not automatically detected in VMs hosted by Virtual Box...
Status: RESOLVED UPSTREAM
Alias: None
Product: Visual Studio Extensions
Classification: Xamarin
Component: iOS ()
Version: 0.x Insider Preview
Hardware: PC Mac OS
: --- normal
Target Milestone: Big Splash Release
Assignee: Jose Miguel Torres
URL:
Depends on:
Blocks:
 
Reported: 2012-12-21 14:57 UTC by GouriKumari
Modified: 2015-01-05 11:20 UTC (History)
7 users (show)

Tags:
Is this bug a regression?: ---
Last known good build:

Notice (2018-05-24): bugzilla.xamarin.com is now in read-only mode.

Please join us on Visual Studio Developer Community and in the Xamarin and Mono organizations on GitHub to continue tracking issues. Bugzilla will remain available for reference in read-only mode. We will continue to work on open Bugzilla bugs, copy them to the new locations as needed for follow-up, and add the new items under Related Links.

Our sincere thanks to everyone who has contributed on this bug tracker over the years. Thanks also for your understanding as we make these adjustments and improvements for the future.


Please create a new report on Developer Community with your current version information, steps to reproduce, and relevant error messages or log files if you are hitting an issue that looks similar to this resolved bug and you do not yet see a matching new report.

Related Links:
Status:
RESOLVED UPSTREAM

Comment 1 Jose Miguel Torres 2013-01-18 03:32:46 UTC
I tried it out and works fine for me. Since this bug was recorded a time ago maybe it is fixed. Please confirm.
Comment 2 Saurabh 2013-02-06 11:13:27 UTC
We have verified this issue with NAT network and we observed that CONNECT_TO_BUILD_HOST not displaying any Mac server. This is the screencast for the same:
http://screencast.com/t/0zgdWObhdPQh

However, This is working fine with Bridge network
Comment 3 PJ 2013-02-06 12:10:58 UTC
Just to clarify on one thing for jose, CONNECT_TO_BUILD_HOST is just the name of the pseudo-workflow of connecting to a build host. So they're just saying they can't connect to a build host with this configuration.
Comment 4 Jose Miguel Torres 2013-02-06 14:17:44 UTC
I don't know what CONNECT_TO_BUILD_HOST stand for algthough I guess that it is such Workflow.

As well I can't detect the mac build host but I can connect to by configuring it manually with the IP.

NOTE: There a bug in the screencast. Diagnose button should be disabled since there is no server selected.
Comment 5 PJ 2013-02-06 16:02:30 UTC
Jose, the bug you mention was filed as https://bugzilla.xamarin.com/show_bug.cgi?id=9706 (and slated for V2).

CONNECT TO BUILD HOST is just the name we gave to the workflow of connecting to the build host for QA purposes. For your needs, it just means connecting to the build host :D.
Comment 6 Jose Miguel Torres 2013-02-07 15:28:43 UTC
IMPORTANT NOTE about NAT utilization:

ZeroConf (Bonjour Service) implementation sends a broadcast message for discovering Bonjour Services across the network without any server configuration. ZeroConf broadcast takes places throughout UDP on port 5353. (In our case ZeroConf is implemented by MTVS (with Mono.ZeroConf) using mDNSResponder.exe (Xamarin Bonjour Service). Our Discovered Service is _MonoTouch._tcp and it's activated by launchctl on the mac side.)

As the result all the production environments (specially the Virtual Machines ones) MUST ensure the UDP broadcast reliability and it could be a problem if the virtual machine is using NAT because of all incoming packages received at UDP:5353 by the Host have to be forwarded to the Guest.

So that tried to forward explicitly the incoming localhost UDP port by running:
$ VBoxManage modifyvm "{My VirtualMachine Name}" --natpf1 "mDNS,udp,127.0.0.1,5353,,5353"

But I didn't get luck. It "rarely" works. I mean, 1 of every 10 chances the Mac build host is detected (using MTVS and MZClient.exe) very poor statistical result. 

I detected that VirtualBox documentation states:

* NAT limitations:
-- Receiving of UDP broadcasts is not reliable:
---The guest does not reliably receive broadcasts, since, in order to save resources, it only listens for a certain amount of time after the guest has sent UDP data on a particular port. As a consequence, NetBios name resolution based on broadcasts does not always work (but WINS always works). As a workaround, you can use the numeric IP of the desired server in the \\server\share notation.

So I think that the useless of NAT in some/all Virtual Machines environments should be reviewed.

* I didn't try out VMWare.
* Marked as NEEDINFO since we need to test it on VMWare and to decide the future of NAT. 

More info | http://www.dns-sd.org/ | http://files.dns-sd.org/draft-cheshire-nat-pmp.txt | http://en.wikipedia.org/wiki/Multicast_DNS | http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers | (http://www.virtualbox.org/manual/ch06.html#natforward)
Comment 8 PJ 2013-02-11 11:02:38 UTC
Ok great investigation in comment 6 jose! This one will just be added to the known issues for the release.
Comment 9 PJ 2013-02-20 06:50:48 UTC
This has been added to the support considerations document, and there is nothing much we can do about it as per comment 6. Marking as RESOLVED UPSTREAM