Submit Hint Search The Forums LinksStatsPollsHeadlinesRSS
14,000 hints and counting!

10.4: Kill Parallels' DHCP server for network testing Apps
I've been playing with Parallels Desktop on OS X as a replacement for Virtual PC on Windows in terms of testing complex Windows network designs. The lack of "undo" disks is still a major problem, but I've found a way to build an internal, isolated network for your VMs (Virtual Machines) to play in.

Parallels, by default, offers two choices for VM networking -- Bridged or Host-only. With Bridged, the VM connects to your Mac's network and is basically on the local network. With Host-only, the VM is placed in an isolated network, as desired. But then Parallels does something annoying: It adds the Mac OS X machine to that isolated network and fires up a DHCP server. While it gives you the ability to adjust the DHCP scope, there is no handy way to turn it off. Killing OS X's Parallels network adapter just dumps the VMs back into Bridged mode.

If, like me, you need to test networks that include a DHCP server (for LDAP settings, NAP settings, etc.), this is a problem. You don't want your host OS X machine to be a DHCP server on your isolated network. Fortunately, this DHCP server is easy to spot in Activity Viewer (or top) -- it's called Prl_dhcpd. Killing this process stops the DHCP server, and lets you run your own DHCP server in the isolated network.

It'll come back on reboot, so kill it again before launching your test machines if you've rebooted since last use. This is what I do (since sometimes I do want it running for casual Parallels use). If you want to prevent it from running on boot, the file is (naturally) located in /Library -> StartupItems -> Parallels. Moving it out of there should stop the "Parallels DHCP server launches on boot" activity, but I haven't bothered to test that. You could also write an Automator action or shell script to kill this process without using Activity Viewer, but I haven't bothered to do that, either :).

Hopefully Parallels will include a nice preferences option to do this in a future update -- I was quite disappointed to discover the DHCP tab had a way to change the scope, but no "turn off" button.
    •    
  • Currently 3.33 / 5
  • 1
  • 2
  • 3
  • 4
  • 5
  (3 votes cast)
 
[21,327 views]  

10.4: Kill Parallels' DHCP server for network testing | 6 comments | Create New Account
Click here to return to the '10.4: Kill Parallels' DHCP server for network testing' hint
The following comments are owned by whoever posted them. This site is not responsible for what they say.
10.4: Kill Parallels' DHCP server for network testing
Authored by: raider on Nov 09, '06 08:17:32AM

The newest build (as of this instant build 1970, although new ones come all the time) of Parallels ads another network mode, "Shared" which is NAT like what Virtual PC used to provide..

Not that this really affects this hint - just as an FYI...



[ Reply to This | # ]
10.4: Kill Parallels' DHCP server for network testing
Authored by: acdha on Nov 09, '06 09:53:37AM
You can actually go farther than this by editing /Library/StartupItems/Parallels/Parallels. I edited the startup option to disable the virtual network adapters (I've never used anything other than bridged networking or no networking) and the DHCP/NAT daemon:
    # Log "Loading Virtual Ethernet module..."
    # loadModule $basePath/Pvsvnic.kext
    # sleep 1

    # Log "Staring DHCP/NAT daemon..."
    # $basePath/pvsnatd
    # sleep 1

    # InternetSharing may have missed our interface
    # Log "Restarting InternetSharing..."
    # /usr/libexec/InternetSharing

    # as well as Cisco VPN client
    # Log "Restaring CiscoVPN..."
    # /System/Library/StartupItems/CiscoVPN/CiscoVPN restart


[ Reply to This | # ]
10.4: Kill Parallels' DHCP server for network testing
Authored by: ephramz on Nov 09, '06 03:27:33PM
I have a very strange networking problem I think is related to installing Parallels and its networking that only occurs with a login type wireless connection at my school, but never with a wired connection there, or other types of wireless connections, encrypted on unencrypted. What use to work a few weeks ago fine, taking me to the login page at "https://bs5000.lehman.cuny.edu/login.pl?action=paint;source=172.16.8.221;destination=http%3A%2F%2Fwww.macosxhints.com%2F%3F;r=OGoe2xc5481"; whenever I typed in any random URL (www.macosxhints.com in this case), now instead appends ":8090/www.lehman.cuny.edu"; to any address so instead I'd go to "www.macosxhints.com:8090/www.lehman.cuny.edu"; in this case. Lehman.cuny.edu is my school's domain.

It still works fine for other people at school, even on Macs. The only thing I can pinpoint I might have changed around the time it stopped working is installing Parallels and a DynDNS transponder, but I've uninstalled both of those, taken all the StartupItems out of my /System/Library and /Library folders, restarted, no change. I don't see any prls or dhcp named process in a ps/Activity Viewer. Any ideas if Parallels might've done something weird to affect this?

[ Reply to This | # ]
10.4: Kill Parallels' DHCP server for network testing
Authored by: sgasp on Nov 10, '06 12:06:08PM

Another way of doing

simply go in Network Mac OS X preference panel and de activate or delete the virtual network interface created by Parallels.

If ou have a DHCP server running on your network (e.g. your DSL box) the Virtual machine will get an IP from it.



[ Reply to This | # ]
10.4: Kill Parallels' DHCP server for network testing
Authored by: legacyb4 on Nov 11, '06 10:35:31PM

Didn't realize that Parallels doesn't have an 'undo' disk feature; that's almost a given on VPC or VMWare and probably the single best reason to use a virtual machine...

---
lumine.net



[ Reply to This | # ]
10.4: Kill Parallels' DHCP server for network testing
Authored by: mikemcg on Nov 28, '06 01:17:23PM

Undo ("snapshots" in VMWare lexicon, I believe; never used VPC) is the single best reason for virtualization? I think it's a convenient feature, but IMHO hardware consolidation, service isolation, hot standby and development/testing are each generally as good or better reasons for going with virtualization.



[ Reply to This | # ]