This is a new problem since moving my OS X host to Leopard, it didn't occur in Tiger. The problem is the OS X host is registering the 172.16.x.x addresses that are being assigned to host only and NAT interfaces in my companies DNS. This is making reverse lookups my host slow and/or incorrect (I suspect it is one of the things making AD logins so slow).
This really should not be happening.
Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.
Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.
I don't know if this is the official way however it's what worked for me...
You need to edit the "/Library/Application Support/VMware Fusion/boot.sh" file.
In Terminal...
$ sudo nano "/Library/Application Support/VMware Fusion/boot.sh"
Near the end of the boot.sh file there are lines as shown below (not together in the file and just shown here for example).
Create virtual interface for the NATted vmnet8
"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8
Create virtual interface for the Host-Only vmnet1
"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1
You need to comment out the two lines that start with '"$LIBDIR/vmnet-netifup"' by placing a "#" in front.
Create virtual interface for the NATted vmnet8
"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8"
Create virtual interface for the Host-Only vmnet1
"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1"
Now restart the boot.sh with...
sudo "/Library/Application Support/VMware Fusion/boot.sh"
After that if you do ifconfig -a you will not see vmnet1: or vmnet8:
Edit: I placed quotes around the 2 lines to be commented in the example because this message board just loves to screw up what's typed sometimes and it's really starting to get annoying! Obviously in the actual file only a "#" is placed in front of the line
Now it may not really be a Fusion problem but what I need to know is how to simply disable the NAT and host only interfaces completely so no address is assigned to be updated in DNS in the first place. I only use bridged networking.
I don't know if this is the official way however it's what worked for me...
You need to edit the "/Library/Application Support/VMware Fusion/boot.sh" file.
In Terminal...
$ sudo nano "/Library/Application Support/VMware Fusion/boot.sh"
Near the end of the boot.sh file there are lines as shown below (not together in the file and just shown here for example).
Create virtual interface for the NATted vmnet8
"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8
Create virtual interface for the Host-Only vmnet1
"$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1
You need to comment out the two lines that start with '"$LIBDIR/vmnet-netifup"' by placing a "#" in front.
Create virtual interface for the NATted vmnet8
"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8"
Create virtual interface for the Host-Only vmnet1
"# "$LIBDIR/vmnet-netifup" -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1"
Now restart the boot.sh with...
sudo "/Library/Application Support/VMware Fusion/boot.sh"
After that if you do ifconfig -a you will not see vmnet1: or vmnet8:
Edit: I placed quotes around the 2 lines to be commented in the example because this message board just loves to screw up what's typed sometimes and it's really starting to get annoying! Obviously in the actual file only a "#" is placed in front of the line
Thank you, that worked. It would be nice to have a better way to do that though.
Thank you, that worked. It would be nice to have a better way to do that though.
I agree however until there is a GUI for these things I don't see another way.
FWIW I always copy the original target file appending an .ori to it and then make my edits once the copy the edited file to a file with an appropriate added extension. I then incorporate the various configurations into into a script which based upon a command line argument copies the target added extension file to the working named file and restart the service in this case. Thus being able to quickly switch between various configurations without having to edit the working file each time.
If I followed your description, vmnet1 and vmnet8 indeed disapear from ifconfig. But when i start my VM (Windows XP), Fusion gives a note that the device "dev" vmnet0 cannot be found/started.
After that I tried the following:
-) sudo rm locations (in the /Library/Application Support/VMware Fusion directory)
-) sudo ./vmware-config-net.pl
-) sudo ./boot.sh --restart
Still it doesn't seem to work for me. Any ideas?
With Kind Regards
I concur with this assessment. I raised Apple Bug ID 664258. We too are experiencing this problem on Mac OS X 10.5.6 machines bound to AD with VMWare installed, and whilst I don't have conclusive proof, either uninstalling VMWare or turning off Bonjour, or unbinding from the AD domain will stop the issue. None of these are palatable solutions though.
The solution suggested on this thread is also unacceptable - we need the vmnet interfaces because we require NAT. (Automatic interface switching, access via the raccoon PPTP implementation and so forth). Although I mention Parallels Desktop in the bug report, I don't think we seem to notice the same issue with Parallels Desktop since its networking plays infinitely nicer with Mac OS X - its interfaces show up in the Network system prefs pane for example.
So, whilst conceding that it's likely a problem in the way mDNSResponder detects interface, it sure would be nice if there was a way to 'cloak' VMWare interfaces from DNS-SD address-based domain enumeration queries.
How about it Fusion guys?
-
Here's the bug report...
Bonjour address-based domain enumeration queries for virtual private interfaces
04-Mar-2009 10:07 AM Marc Bailey:
Summary
-
What is the "defined" DNS-SD behaviour for address-based domain
enumeration queries on virtual interfaces with RFC1918 private address
space?
Steps to Reproduce
-
A Mac OS X 10.5.6 computer running VMWare Fusion or Parallels
Desktop ends up with a number of virtual network interfaces in RFC1918
private address space.mDNSResponder periodically issues address-based domain enumeration
queries for all network base addresses by bitwise AND of mask and
address.For example, for a standard vmnet interface of 172.16.162.1/24 Bonjour issues DNS queries like:PTR lb._dns-sd_udp.0.162.16.172.in-addr.arpa.
The problem is that these address zones do not exist because they
are artefacts of the VM environments, and since there are five standard
bonjour domains, you get a heap of NXDOMAIN replies with 2 second
timeout latency. Rinse and repeat. Frequently.
Actual Results
-
We can't yet precisely confirm, but believe that this is causing
large problems with Active Directory bound Macs. A typical Mac Book Pro
with Parallels and VMWare, GigE and Wifi connections will offer seven
interfaces, five of which are virtual. So, five domain enumerations X
five interfaces x 2 second delay = 50 seconds.For some reason we see blocking behaviour at login time; login
appears to be stalled (beachballed) and the only traffic seems to be
unicast DNS-SD queries of this form - even though kerberos handshaking
is working fine.Only after mDNSResponder gives up on these queries can a user
login. This can take minutes. It's almost like Bonjour is being
consulted to discover AD services - which of course makes no sense.
Expected Results
-
What is the "defined" DNS-SD behaviour here? Should virtual
interface domain enumeration queries even make it out of the machine? I
am guessing the answer to that is a firm 'no'.
Regression
-
sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.mDNSResponder.plistresults in elimination of login delays and timeouts.It also, naturally, is very undesirable because it shuts down Bonjour completely.
Notes
-
I'm requesting clarification from the Bonjour team as to what is
"supposed" to happen for these kinds of interfaces. Then happy to take
this to VMware or Parallels for resolution if they are doing the wrong
thing somehow or if there is no way for mDNSResponder to recognise
their interfaces as 'virtual'.Another possibility might be to provide an explicit
include/exclude interface plist/config file for Bonjour to manually
confine mDNSResponder to physical interfaces only.
[ [Show »|http://jira.objective.com/browse/IMG-4376]]
[Marc Bailey|http://jira.objective.com/secure/ViewProfile.jspa?name=marc] -
04/Mar/09 10:16 AM Raised Apple bug ID 6642581
Bonjour address-based domain enumeration queries for virtual private
interfaces
04-Mar-2009 10:07 AM Marc Bailey:
Summary
-
What is the "defined" DNS-SD behaviour for address-based domain
enumeration queries on virtual interfaces with RFC1918 private address
space?
Steps to Reproduce
-
A Mac OS X 10.5.6 computer running VMWare Fusion or Parallels Desktop
ends up with a number of virtual network interfaces in RFC1918 private
address space.
mDNSResponder periodically issues address-based domain enumeration
queries for all network base addresses by bitwise AND of mask and
address.
For example, for a standard vmnet interface of 172.16.162.1/24 Bonjour
issues DNS queries like:
PTR lb._dns-sd_udp.0.162.16.172.in-addr.arpa.
The problem is that these address zones do not exist because they are
artefacts of the VM environments, and since there are five standard
bonjour domains, you get a heap of NXDOMAIN replies with 2 second
timeout latency. Rinse and repeat. Frequently.
Actual Results
-
We can't yet precisely confirm, but believe that this is causing large
problems with Active Directory bound Macs. A typical Mac Book Pro with
Parallels and VMWare, GigE and Wifi connections will offer seven
interfaces, five of which are virtual. So, five domain enumerations X
five interfaces x 2 second delay = 50 seconds.
For some reason we see blocking behaviour at login time; login appears
to be stalled (beachballed) and the only traffic seems to be unicast
DNS-SD queries of this form - even though kerberos handshaking is
working fine.
Only after mDNSResponder gives up on these queries can a user login.
This can take minutes. It's almost like Bonjour is being consulted to
discover AD services - which of course makes no sense.
Expected Results
-
What is the "defined" DNS-SD behaviour here? Should virtual interface
domain enumeration queries even make it out of the machine? I am
guessing the answer to that is a firm 'no'.
Regression
-
sudo launchctl unload -w
/System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
results in elimination of login delays and timeouts.
It also, naturally, is very undesirable because it shuts down Bonjour
completely.
Notes
-
I'm requesting clarification from the Bonjour team as to what is
"supposed" to happen for these kinds of interfaces. Then happy to take
this to VMware or Parallels for resolution if they are doing the wrong
thing somehow or if there is no way for mDNSResponder to recognise
their interfaces as 'virtual'.
Another possibility might be to provide an explicit include/exclude
interface plist/config file for Bonjour to manually confine
mDNSResponder to physical interfaces only.
</div>
</div>
</div>