1 3 4 5 6 7 Previous Next 176 Replies Latest reply on Sep 17, 2011 8:40 AM by WoodyZ Go to original post
      • 60. Re: Scripts to manage Fusion network settings
        DaveP Master



        I'll be home soon to check this out my Mac. Sorry haven't been around, but work's been busy. Before I get home can you post:


        1. locations file from tokamak backup directory

        2. locations file from /Library/Application Support/VMware Fusion directory

        3. Version of VMware being used

        4. Veriosn of Mac OS X being used


        Note that tokamak.sh does not directly modify the locations file, that is done by the Perl file which is primarily VMware code (Fusion plus a touch of the Linux version).

        • 61. Re: Scripts to manage Fusion network settings
          DaveP Master

          It's an issue with VMware Fusion. I should add a note to that effect. Disabling one seems to disable the other. I will do some new tests on Fusion 2.0.1, but this behavior has been seen in all releases of Fusion until now. But if you can answer the other questions we may also have a issue with the way your locations files are being built.

          • 62. Re: Scripts to manage Fusion network settings
            sirozha Novice



            Thanks for your response. I will post the files you requested from home tonight.


            The version of Mac OS is 10.5.5 (the latest version with all the updates).



            The version of VMWare Fusion is the latest trial available on the VMWare site.



            I am still trying to decide between VMWare and Parallels. I need to run virtual machines for my VoIP lab to use Cisco voice servers as guest OSes. I will also be running VMWare Server for Linux on a stationary server, so I would rather stick with Fusion for I hear a lot of code is the same on the Linux and the Mac platforms, so the trouble shooting should be easier if I run VMWare on both my Mac and the Intel server. However, the lack of functionality to add, remove, or modify VMNets, to enable or disable the DHCP server and NAT, etc. in VMWare Fusion is holding me back from purchasing VMWare Fusion. I need to make sure that all the tasks that I need to do with my virtual machines can be accomplished in VMWare Fusion with these scripts before I purchase VMWare Fusion. So far, I have not had any need to install Windows on my Mac, and my goals are a little more demanding than just running Windows under VMWare Fusion.



            I have not yet tried Paralles for the same purpose, but I have heard that Parallel's GUI has a lot more options to modify virtual networks than Fusion's GUI. I just wish VMWare would bring Fusion up to par with VMWare Workstation for Linux and for Windows.

            • 63. Re: Scripts to manage Fusion network settings
              DaveP Master



              I've used both Parallels and VMware products on all three platforms, Windows, Linux and Mac OS X and have to say VMware beats Parallels every time for stability and speed for the sorts of things I do. As for the scripts, I will have another look at them. Maybe the underlying issues have gone away in the DHCP and NAT daemons. There are other ways to tailor the system, by directly editing the boot.sh script, and even hard coding values in there. However, I would like to see if there is something I can do in the scripts to make them more useful.


              So to summarize your requirements:


              1. Create additional VMnets

              2. Tailor IP and subnet masks

              3. Decide on DHCP and NAT for each interface - which is currently the problem


              I'll also look at the one liner patch above for the tokamak-boot.sh BASH script. Hope we can get everything sorted out.




              Update: OK by manually entering the following commands I was able to get what you wanted:


              ./vmnet-dhcpd -cf "/Library/Application Support/VMware Fusion/vmnet8/dhcpd.conf" -lf /var/db/vmware/vmnet-dhcpd-vmnet8.leases -pf /var/run/vmnet-dhcpd-vmnet8.pid vmnet8

              ./vmnet-natd -c "/Library/Application Support/VMware Fusion/vmnet8/nat.conf" -m "/Library/Application Support/VMware Fusion/vmnet8/nat.mac" -d /var/run/vmnet-natd-vmnet8.pid vmnet8

              ./vmnet-netifup -d /var/run/vmnet-netif-vmnet8.pid vmnet8 vmnet8

              ifconfig vmnet8 inet netmask

              ./vmnet-netifup -d /var/run/vmnet-netif-vmnet1.pid vmnet1 vmnet1

              ifconfig vmnet1 inet netmask


              This gives the following output:


              VM@Work Tokamak 2.0.0: Extended network scripting - Dave Parsons

              Host-only/NAT networking on vmnet1 using is running

              DHCP server on vmnet1 is not running

              Host-only/NAT networking on vmnet8 using is running

              DHCP server on vmnet8 is running

              NAT networking on vmnet8 is running


              Now to see how to code this into the scripts. It may well be as simple as the one line fix, but will check it out over the next day or so. Hopefully you can wait a day?

              • 64. Re: Scripts to manage Fusion network settings
                sirozha Novice



                I am attaching both of my locations files; the first one is from the tokamak directory, and the second one if from the /Library/Application Support/VMWare Fusion/



                Of course I can wait for these scripts. Thanks for doing this.



                By the way, have you tried Parallels Desktop 4.0 yet? I heard it beats VMWare Fusion 2.0 on speed. There's a review on informatin week:






                What I am interested in is how Parallels Desktop 4.0 handles the tasks of changing ip addresses on virtual networks and DHCP issues on host-only and NATed networks.

                • 65. Re: Scripts to manage Fusion network settings
                  DaveP Master

                  I need to alter both the tokamak-config-net.pl and tokamak-boot.sh scripts to allow DHCP to be selected separately. I am now working on the code and hopefully will have a new version available sometime over the weekend. Hope that helps you out.

                  • 66. Re: Scripts to manage Fusion network settings
                    DaveP Master

                    If anyone wants to try it I have uploaded a beta of 2.1.0. Now you can specify DHCP use for both hostonly and nat virtual interfaces. I haven't yet worked out whether this is a good or bad things and how it impacts guests, so if you are interested try it and let me konw how it goes. I'll then write up some scenarios and publish.



                    Before installing please ensure that you:


                    1. Uninstall any previous version as locations database has changed slightly

                    2. VMware is not running when you do this



                    • 67. Re: Scripts to manage Fusion network settings
                      sirozha Novice





                      I just came back from the holidays, so I will try your beta script within the next few days. One thing, though. How do I uninstall the previous version of the script?






                      • 68. Re: Scripts to manage Fusion network settings
                        WoodyZ Guru
                        sirozha wrote:

                        One thing, though. How do I uninstall the previous version of the script?


                        If you read the documentation it will tell you!


                        Advanced Networking Configuration - Tokamak Networking Scripts for VMware Fusion


                        Also in the VM@Work Tokamak.pdf file that is in the tokamak200.zip you downloaded.

                        • 69. Re: Scripts to manage Fusion network settings
                          sirozha Novice



                          Thanks for your work! I have tried the tokamak210b1 beta script you posted the other day, and I got it working. I did run into a few issues, though.


                          1. When I ran sudo ./tokamak.sh --uninstall, using the 2.0 version of your script, for some reason, I could no longer see vmnet1 or vmnet8 when issuing ifconfig. I then ran the 2.10b1 script, using the sudo ./tokamak --install command, but the virtual interfaces were still not listed by the ifcondfig command. So, I had to uninstall VMWare Fusion and then reinstall it.


                          2. Once I reinstalled VMWare fusion and installed tokamak210b1, I I ran sudo ./tokamak.sh --modify However, on the first run of the srcipt with the modify option it reported an error and quit. I then re-ran it with the --modify option, and it worked on the second attempt. You may want to look at this because this happens every time after a fresh installation of tokamak210b1.


                          3. I noticed that when you first install tokamak210b1, the script reports that the DHCP server is "not running" on vmnet1 and "disalbed" on vmnet8. Additionally, NAT "is not running" on vmnet8. I believe this behavior is incorrect because by default vmnett1 is a hostonly virtual network with DHCP enabled, and vmnet8 is a NAT virtual network, in which both DHCP and NAT should be enabled and running. However, when I ran sudo ./tokamak.sh --modify and enabled DHCP on vmnet8, the script showed that both DHCP and NAT are enabled on vment8. So, the only thing that needs to be fixed is that VMWare's defaults should be honored, in my opinion.


                          MB:tokamak210b1 sirozha$ sudo ./tokamak.sh --install


                          VM@Work Tokamak 2.1.0: Installer started

                          VM@Work Tokamak 2.1.0: Stop daemons and kexts

                          VM@Work Tokamak 2.1.0: Create backup folders

                          VM@Work Tokamak 2.1.0: Save original files

                          VM@Work Tokamak 2.1.0: Set boot script

                          VM@Work Tokamak 2.1.0: Display settings

                          The following virtual networks have been defined:


                          . vmnet1 is a host-only network on private subnet

                          . vmnet8 is a NAT network on private subnet


                          VM@Work Tokamak 2.1.0: Extended network scripting - Dave Parsons

                          Host-only/NAT networking on vmnet1 using is not running

                          DHCP server on vmnet1 is not running

                          NAT networking on vmnet1 is disabled

                          Host-only/NAT networking on vmnet8 using is not running

                          DHCP server on vmnet8 is disabled

                          NAT networking on vmnet8 is not running

                          VM@Work Tokamak 2.1.0: Installer completed


                          The above results are with the full version (not trial) of VMWare Fusion 2.0.1 and tokamak210b1. There's an option now to disable DHCP on the hostonly and nat vmnets when you run the script with the --modify option. I chose not to use DHCP on vmnet1 when I ran ./tokamak.sh --modify, and the script reported that DHCP is disabled on vmnet1. I have not verified if it is in fact disabled.


                          4. The task that I have at hand is to run a Cisco Unified Communications Manager (CUCM) 6.1 under VMWare Fusion. Sometimes, I need the environment to be hostonly (when I am not connected to any network). Other times, if I am on a wireless network, I need the environment to be bridged to the Airport inteface on my Mac, which is en1. Another requirement is that the IP range in both of these environments should remain the same (namely,, which is needed in order for the CUCM to keep the same IP address and default gateway regardless of which environment it currently is (bridged or hostonly).






                          By default, vmnet1 is bridged to en0, which is the Gigabit Ethernet NIC on my Mac. I was able to change the bridge that vmnet1 uses to en1 (Airport), using your script. However, what I noticed is that if I switch the virtual machine running the CUCM from hostonly to bridged (using Fusion's GUI), I can ping hosts on the network as well as my Mac's Airport IP address from the CUCM. If I switch the virtual machine's interface from bridged to hostonly (using Fusion's GUI), I cannot ping interface vmnet1 on my Mac. I tried to turn the Airport card off in Mac OS and even use sudo ifconfig en1 down, but I still couldn't ping interface vmnet1 from the CUCM. This seems to result from the Mac's routing table not being updated correctly when switching the environment from bridged to hostonly using Fusion's GUI, and may very well be a bug in Fusion. This becomes obvious when you issue the netstat -r command after you switch from bridged to hostonly in Fusion's GUI. The routing table fails to use interface vmnet1 for the route to What I had to do is to issue sudo ifconfig vmnet1 down followed by sudo ifconfig vmnet1 up. Only after that my hostonly environment starts working again, and the routing table reflects the fact that packets to are routed via interface vmnet1.



                          Even though I am not planning to run Windows under VMWare Fusion, I would like to understand how VMWare users are expected to install Windows on their Macs and be able to bridge to WiFi interfaces without resorting to Dave's tokamak script. Obviously, users of VMWare products for Windows and Linux don't have this problem because the ability to change the bridge to any physical interface is already in the GUI of those products.









                          5. When troubleshooting connectivity, pinging the Host's virtual interfaces (vmnetX) from the VMWare Guest OS's interface doesn't work if the Mac OS' firewall is enabled and the stealth mode is on. To fix the connectivity, the stealth mde should be turned off or the firewall should be disabled altogether. This appears to be a shortcoming of the Mac OS' GUI firewall. Apple should have provided an option to disable the stealth mode for the hosts located on the same subnet but to keep the stealth mode for all other hosts in the GUI of the firewall. I don't know if other types of TCP/IP connections (besides ICMP) are allowed in the inbound direction to the virtual interfaces (vmnetX interfaces) when the stealth mode is enabled -- I have not yet tested this scenario.



                          So, the following issues still need fixing:



                          a. VMWare DHCP server and NAT defaults for vmnet1 and vmnet8 should be honored when tokamak is first installed, in my opinion.



                          b. A fix needs to be implemented for the first run of tokamak.sh --modify to prevent it from quiting with an error message.



                          c. It seems that at the end of the session when tokamak is used with the --modify option, the script prompts to enter yes or no as the response to whether or not the user wants to continue editing the settings. However, the script only accepts y or n. It does not accept yes or no.



                          d. It would be nice to get the ability to assign custom IP addresses to interfaces vmnetX instead of having to stick to .1 in the fourth octet of the IP address assigned to the Mac's virtual interface created by VMWare. When I tried to assign to interface vmnet1, using tokamak 210b1, even though the script didn't complain, the IP address assigned to vmnet1 was



                          e. Consider the possibility of bypassing the Mac OS' firewall in the hostonly environment because there's no reason for the firewall to protect a virtual interface from the guest OS if there's no bridging going on to the physical interface, and hence, there's no external threat. I don't know if this is something that could be done at the tokamak level of if this is something that VMWare should consider implementing in their next release of VMWare Fusion.

                          • 70. Re: Scripts to manage Fusion network settings
                            tramahound Novice


                            I don't know if this is off topic, but I thought this would be the best place to pose the question. In the documentation it states;



                            Do NOT remove the vmnet0, vmnet1 and vmnet8 adapters. Doing so will cause the VMware daemons for networking to fail. It is OK to change the IP addresses.



                            I'm having an issue at work where the virtual interfaces (VMNET1 & 8) are causing traffic and logging issues on our cisco firewall which is turning up the heat for me from my Mac hating boss. It seems that the 192.168.x.x addresses are being advertised which causes traffic on our network for such things as CIFS and SMB. To try and get around this I installed NoobProof and denied those protocols and more. This appeased my boss, but not for long. Now he's working on cleaning up our junked up cisco firewall logs and found that a lot of machines on my subnet are trying to connect to my machine's 192.168.x.x address on vmnet8 which is NAT right? I don't know why this would be and how to stop it but I turned to the command 'sudo killall vmnet-netifup' to get rid of both vmnet1 and 8. I assume they will respawn once I reboot, but for now it bought me some time. I was looking into using the scripts mentioned here in order to further neuter my Fusion install and make my boss happy, but was worried about the implications of doing so based on the above comment. Is my killall command actually removing them or just disabling them? And is it even possible using these scripts to disable them each and every time I reboot?



                            Any and all help would be appreciated since I would really prefer using my 8 core Mac Pro over a dinky HP desktop at work! 



                            • 71. Re: Scripts to manage Fusion network settings
                              sirozha Novice

                              You should be able to disable both vmnet1 and vmnet8, using David's script. However, I am not sure what the original problem is. You Mac cannot "advertise" anything to the network because it is not running a routing protocol. Additionally, firewalls normally don't run routing protocols either, so they usually cannot receive any routing updates. Depending on your topology, you may have your Mac's default gateway pointing to the inside interface of the firewall. When you Mac needs to send a packet to another network, it would first ARP for your default gateway's Mac address, and your Firewall would respond with its MAC address (if the firewall is the default gateway). When the firewall needs to send something to the Mac, it would ARP for the Mac's IP address. If you your guest OS is connected to your host (Mac) via the "bridged" connection, then your guest OS's virtual network interface will respond to the ARP request with its virtual MAC (different from Mac) address. In this case, any host on the network can talk directly to your guest OS. If, on the other hand, your guest OS is connected to the network via the "NAT" connection, then your Mac is tasked with translating the IP address assigned to the virtual network interface of your guest OS into the IP address assigned to the physical network interface on the Mac itself; therefore, the MAC address used in the ARP replies will be the Mac's physical nework interface's MAC address. In the case of the "NAT" connection of your guest OS, the IP subnet configured on vmnet8 will not be visible to any physical network device besides your Mac.


                              So, please find out what exactly the firewall logs are showing and report it here so that we can try to help you.


                              If you want to turn your vmnet interfaces off temporarily, use the following commands:


                              sudo ifconfig vmnet1 down


                              sudo ifconfig vmnet8 down



                              If you guest OS is bridged to your Mac's physical network interface, then bringing down vmnet1 and vmnet8 should not affect the traffic to your guest OS.



                              In order to bring vmnet1 and vmnet8 back up, use the following commands:



                              sudo ifconfig vmnet1 up



                              sudo ifconfig vmnet8 up



                              Also, you may want to use the netstat -r command on your Mac to see out of which nework interface the default route ( is pointing -- it should be pointing out of one of your Mac's physical interfaces (usually en0 - ethernet; or en1 - Airport). On the other hand, in your guest OS (if it's Windows), you can go to the command prompt and issue the same command: netstat -r. In the "bridged" mode, the route should have the gateway's IP address to be the default gateway on your LAN (the same one that your Mac has as its default gateway -- this may be the inside interface of your firewall). If your guest OS is in the "NAT" mode, the gateway on the route should be the IP address configured on vmnet8 on your Mac. You can see what that address is if you issue the ifconfig command on your Mac. If you switch between the "bridged' mode and the "NAT" in VMWare Fusion, you would have to reacquire the IP address on your guest OS (Windows), by using the following commands:



                              ipconfig /release



                              ipconfig /renew

                              • 72. Re: Scripts to manage Fusion network settings
                                tramahound Novice

                                I was only sent a snippet from the Ciscoworks ASA log file, but according to our network admin traffic going to my vmnet1 interface was being logged there for denials every second! All it shows is the ip address of other computers along with "Inbound TCP connection denied from 10.33.4.x/7307 to flags SYN on interface inside"

                                I had an SMB share running before, but even after turning it off and removing it the connection attempts still came in. It wasn't until actually disabling the entire interface that they stopped.

                                according to my netstat -r results my default route is set correctly on both my host and guest on en0.

                                • 73. Re: Scripts to manage Fusion network settings
                                  rickf101 Novice





                                  Will your scripts allow me to create an additional vmnet (say vmnet2) which is bridged to en1 while keeping vmnet0 bridged to en0? If so, what glue is necessary in the guest vmx file to tie a virtual network adapter to this second bridge?












                                  • 74. Re: Scripts to manage Fusion network settings
                                    WoodyZ Guru
                                    rickf101 wrote:

                                    Will your scripts allow me to create an additional vmnet (say vmnet2) which is bridged to en1 while keeping vmnet0 bridged to en0? If so, what glue is necessary in the guest vmx file to tie a virtual network adapter to this second bridge?


                                    Yes it will however have a look at the Document DaveP did on this for directions: Advanced Networking Configuration - Tokamak Networking Scripts for VMware Fusion

                                    1 3 4 5 6 7 Previous Next