VMware Communities
DaveP
Commander
Commander

Scripts to manage Fusion network settings

VM@Work Tokamak 1.0.0

Well I have finally found time to finish the scripts to manage the virtual network settings for VMware Fusion. Real world work got in the way of me finishing it for a few weeks. I have been using this for about a month now, and have not seen any ill effects from it. There is a preliminary document describing the functionality of the script, called VM@Work Tokamak. (Yes cheesy pun on Fusion!). The scripts bring the functionality of the VMware Workstation 6 for Linux product to Mac OS X. It allows you to define new networks, modify existing settings, change bridged etc. In this version I have limited the number of configurable vmnets to 10, but if more is needed it can be quickly altered.

The work has been released after VMware gave me permission to re-distribute their code. I would ask that you respect this and don't repost. It will be available here using the new document feature and at my web site, once I have had time to update it. In the meantime, please feel free to post comments here, PM me or use my private email address. All feedback gladly accepted.

My thanks to Pat Lee, Product Manger for VMware Fusion for helping get permission to modify the code and re-distribute.

Dave

Message was edited by: DaveP

There is an issue with the scripts when adding new vmnets. Unfortunately as I am on vacation I can't fix it as no access to Mac. Will fix and upload next week.

Reply
0 Kudos
176 Replies
DaveP
Commander
Commander

Guys

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).

Reply
0 Kudos
DaveP
Commander
Commander

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.

Reply
0 Kudos
sirozha
Contributor
Contributor

Dave,

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.

Reply
0 Kudos
DaveP
Commander
Commander

Hi

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.

Dave

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 172.16.8.1 netmask 255.255.255.0

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

ifconfig vmnet1 inet 172.16.1.1 netmask 255.255.255.0

This gives the following output:

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

Host-only/NAT networking on vmnet1 using 172.16.1.1/255.255.255.0 is running

DHCP server on vmnet1 is not running

Host-only/NAT networking on vmnet8 using 172.16.8.1/255.255.255.0 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?

Reply
0 Kudos
sirozha
Contributor
Contributor

Dave,

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.

Reply
0 Kudos
DaveP
Commander
Commander

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.

Reply
0 Kudos
DaveP
Commander
Commander

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.

NOTE:

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

Dave

Reply
0 Kudos
sirozha
Contributor
Contributor

Dave,

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?

Thanks!

Reply
0 Kudos
WoodyZ
Immortal
Immortal

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.

Reply
0 Kudos
sirozha
Contributor
Contributor

Dave,

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

Password:

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 192.168.208.0.

. vmnet8 is a NAT network on private subnet 192.168.102.0.

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

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

DHCP server on vmnet1 is not running

NAT networking on vmnet1 is disabled

Host-only/NAT networking on vmnet8 using 192.168.102.1/255.255.255.0 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, 192.168.200.0 255.255.255.0), 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 192.168.200.0/24. 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 192.168.200.0/24 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 192.168.200.100 to interface vmnet1, using tokamak 210b1, even though the script didn't complain, the IP address assigned to vmnet1 was 192.168.200.1

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.

Reply
0 Kudos
tramahound
Contributor
Contributor

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 & 😎 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!

Reply
0 Kudos
sirozha
Contributor
Contributor

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 (0.0.0.0) 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 0.0.0.0 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 0.0.0.0 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

Reply
0 Kudos
tramahound
Contributor
Contributor

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 192.168.79.1/139 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.

Reply
0 Kudos
rickf101
Contributor
Contributor

Dave,

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?

Thanks,

Rick

Reply
0 Kudos
WoodyZ
Immortal
Immortal

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:

Reply
0 Kudos
rickf101
Contributor
Contributor

Yes, I did look at that document. It talks about "Changing the physical interface used for bridged connections" but it doesn't discuss how to set up bridged connections to two physical interfaces simultaneously.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

There is a very good reason why this is for advanced users. If you just run the script it should be obvious.

As an example when I run the script here is the first part of the output...

macbookpro:tokamak200 WKZ$ sudo ./tokamak.sh --modify
You have already setup networking.

Would you like to skip networking setup and keep your old settings as they are? 
(yes/no) [yes] n

Do you want networking for your virtual machines? (yes/no/help) [yes] y

Would you prefer to modify your existing networking configuration using the 
wizard or the editor? (wizard/editor/help) [wizard] w

Configuring a bridged network for vmnet0.

Your computer has multiple ethernet network interfaces available: en0, en1, en2,
en3. Which one do you want to bridge to vmnet0? [en0] 

The select the ethernet network interface you want.

Reply
0 Kudos
rickf101
Contributor
Contributor

I appreciate your response but this still is not answering my question. While I'm new to Mac OS-X, I've been a Unix kernel developer dating back to Unix System V Release 2 (circa 1988).

I have looked at the script output and I see that you can associate different physical interfaces with different vmnet's. My question is how do you tie a specific vmnet to a virtual interface for a given guest? In the guest's VMX file, I see ethernet0.connectionType = "bridged". I don't see any way to specify WHICH bridge.

I want to bridge en0 to vmnet0, en1 to vmnet2 (step A), and then connect the guest's ethernet0 to vmnet0 and ethernet1 to vmnet2 (step B).

I see how to do step A, I don't see how to do step B.

Reply
0 Kudos
WoodyZ
Immortal
Immortal

I appreciate your response but this still is not answering my question. While I'm new to Mac OS-X, I've been a Unix kernel developer dating back to Unix System V Release 2 (circa 1988).

>

I want to bridge en0 to vmnet0, en1 to vmnet2 (step A), and then connect the guest's ethernet0 to vmnet0 and ethernet1 to vmnet2 (step B).

With that much experience one would think you'd read the entire document and the answer you seek is in that document much less the "VM@Work Tokamak.pdf" file that is in the tokamak200.zip file.

Suggest you reread it and specifically the "4.0 Modify Guest VMX File" section.

Reply
0 Kudos
rickf101
Contributor
Contributor

Well, I had previously downloaded the latest (tokamak210b1.zip) which doesn't have the PDF in it. I just downloaded 200 and I see the PDF. It does answer my question.

Thanks!

Reply
0 Kudos