Static IPs From DHCPD In VMware Fusion

Most of my virtual machines for VMware Fusion use NAT for networking to avoid conflicts with external IPs.  However, by default, you only get dynamically assigned IPs albeit almost the same IP for each VM you run.  What I want is a real static IP assigned for each VM.

I navigate to the following directory using the bash shell in the Terminal screen:

    /Library/Application Support/VMware/vmnet8

If you do an ‘ls‘ to see the contents of the directory, you’ll find a file called dhcpd.conf.  (Note:  Your installation may have a different vmnetx directory.  Just make sure you do get to modify the right one.)  It is this file that we’re interested in.  I edit this file and add some entries to enable static IP assignment for each VM I want to have a static IP:

# Configuration file for ISC 2.0 vmnet-dhcpd operating on vmnet8.
#
# This file was automatically generated by the VMware configuration program.
# See Instructions below if you want to modify it.
#
# We set domain-name-servers to make some DHCP clients happy
# (dhclient as configured in SuSE, TurboLinux, etc.).
# We also supply a domain name to make pump (Red Hat 6.x) happy.
#

###### VMNET DHCP Configuration. Start of "DO NOT MODIFY SECTION" #####
# Modification Instructions: This section of the configuration file contains
# information generated by the configuration program. Do not modify this
# section.
# You are free to modify everything else. Also, this section must start
# on a new line
# This file will get backed up with a different name in the same directory
# if this section is edited and you try to configure DHCP again.

# Written at: 03/21/2010 10:15:52
allow unknown-clients;
default-lease-time 1800;                # default is 30 minutes
max-lease-time 7200;                    # default is 2 hours

subnet 172.16.167.0 netmask 255.255.255.0 {
        range 172.16.167.128 172.16.167.254;
        option broadcast-address 172.16.167.255;
        option domain-name-servers 172.16.167.2;
        option domain-name localdomain;
        default-lease-time 1800;                # default is 30 minutes
        max-lease-time 7200;                    # default is 2 hours
        option routers 172.16.167.2;
}
host vmnet8 {
        hardware ethernet 00:50:56:C0:00:08;
        fixed-address 172.16.167.1;
        option domain-name-servers 0.0.0.0;
        option domain-name "";
        option routers 0.0.0.0;
}
####### VMNET DHCP Configuration. End of "DO NOT MODIFY SECTION" #######

host mesmer {
    hardware ethernet 00:0c:29:95:20:3d;
    fixed-address 172.16.167.4;
    option domain-name "hq.linuxunbound.com";
}

host spock {
    hardware ethernet 00:0c:29:bf:2e:05;
    fixed-address 172.16.167.5;
    option domain-name "hq.linuxunbound.com";
}

host starscream {
    hardware ethernet 00:0c:29:2e:ab:d6;
    fixed-address 172.16.167.6;
    option domain-name "hq.linuxunbound.com";
}

host beaker {
    hardware ethernet 00:0c:29:34:1c:7e;
    fixed-address 172.16.167.7;
    option domain-name "hq.linuxunbound.com";
}

host tomahawk {
    hardware ethernet 00:0c:29:ca:37:14;
    fixed-address 172.16.167.8;
    option domain-name "hq.linuxunbound.com";
    option host-name "tomahawk";
}

Note above that I extracted the Ethernet addresses from /sbin/ifconfig while the VM was running.  Also note that the entries I made were done after the end of the “DO NOT MODIFY” section.  In the last entry for host tomahawk, I added the following entry to let DHCPD assign the hostname automatically:

option host-name “tomahawk”;

After adding everything in dhcpd.conf, I shutdown the VMs running properly and quit VMware Fusion completely.  Then, back in Terminal, I change directory to

    /Library/Application Support/VMware/

and execute the following command:

    sudo ./boot.sh --restart

The above command restarts the processes (such as DHCPD) needed by VMware Fusion to properly run the VMs.

I then start VMware Fusion once more and run the VMs.  Each VM that was specified to receive a static IP in dhcpd.conf does indeed get the right IP.

Installing CentOS 5.4 on VMware Fusion 3

For those of us who have Macs, it is really useful to be able to run virtual machines loaded with other operating systems.  VMware Fusion 3 is one product that enables us to run another OS within Mac OS X.  One can even run Mac OS X (Snow Leopard or Leopard) Server in a virtual machine.

This article simply shows the sequence of steps taken to install CentOS 5.4, a Linux distribution based on an enterprise-grade OS (with the non-free parts not included) that has a good share of the Linux enterprise market.  We also show the settings used in VMware Fusion 3.

The Mac that is used here is a unibody aluminum MacBook (October 2008) with a 2.4 GHz Intel Core 2 Duo processor and 4 GB of DDR3 RAM.  It’s a speedy machine even if it has been superseded by the 13″ MacBook Pro.

We first specify the OS disc image for VMware to install from:

Specifying Disc Image for CentOS 5.4

VMware Fusion detects the OS correctly:

64-Bit CentOS Detected

64-Bit CentOS Detected

Initially, VMware Fusion automatically configures the virtual machine settings for you.  Later on we change these settings:

Default Settings For VM

Default Settings For VM

Changing the settings, we then have:

New Settings For VM

New Settings For VM

With the new settings, we can take advantage of the two cores of the CPU.  Note that, unlike the previous version of VMware Fusion, VMware Fusion 3 now shows multiple cores not as individual processors but as individual cores.  This is more obvious with OSes such as Microsoft Windows XP Home Edition which supports multi-core processors but not multiple sockets (you’ll need XP Professional for that).

With the VM configured, we start it and see the splash screen:

Splash Screen

Splash Screen

We press the <ENTER> key and proceed:

Prompt for Testing The Installation Disc/Image

Prompt for Testing The Installation Disc/Image

For the purpose of this article, we skip the test (we previously verified its signature anyway) but it is good to go through the disc for installation on production machines just to be sure.

Below, we see that the next step is the initialization of the Anaconda installer and X.  The installer detects a “vmware video card” and loads that for X.

Starting The Anaconda Installer and X

Starting The Anaconda Installer and X

In a few seconds, X starts up and we see the graphical installer:

The Graphical Installer

The Graphical Installer

We click on “Release Notes” to read what’s new or significant with this release of CentOS.

Release Notes

Release Notes

All we get though is a short version of the release notes with links to various informational documents.  For now, we do not click on any of them and just continue with the installation.

Language Choice for Install

For the purpose of this article, we choose English as the language for installation.

Keyboard Setup and Drive Formatting

We are using a U.S. English keyboard so that is selected.  Then, the installer detects that the partition table is not readable, prompting us to initialize it.  We select ‘Yes’.

Partitioning The Hard Drive

We simply use the default partitioning that the installer chooses and proceed to the next screen.

Network Configuration

For the network configuration, we use DHCP.  When our VM was configured, we chose NAT networking meaning that the OS is “behind” the host OS.  The guest OS (CentOS 5.4 in this case) gets its IP address from VMware and uses that to connect to the local network and the Internet.

Manually Selecting The Hostname

The hostname was chosen manually instead of relying on DHCP to assign it.  This is only for this case.  Your DHCP server might be configured to set the hostname as well — just ask the network/systems administrator about it.

Next, the time and date are configured and the timezone is selected:

Time Zone Selected

The installer then asks for the root/administrator password that is to be used.

Root Password

The packages are now selected.  We select both Gnome and KDE desktop environments just to see how they compare.  Normally, Gnome is selected as default.

Package Selection

We do not need the other packages:

Packages Not Installed

The installer then checks for dependencies for the selected packages (that are going to be installed).

Dependencies

We are prompted to begin installation and so we proceed:

Starting Installation

CentOS Install Begins

Transferring Disc Image

You can donate to the CentOS Project:

Donations, Anyone? :-)

Yum is useful in managing the packages of the system:

Yum

The software repositories:

Software Repositories

The CentOS Plus repository:

CentOS Plus Repository

Help With CentOS

Documentation

CentOS Wiki

Virtualization

Completed Installation

Server Rebooting: Splash Screen of Boot Up

A little more configuration is needed after the reboot:

Some More Configuration

We open up a number of ports needed for the installation to service clients with.

Firewall

We set SELinux to “Enforcing”:

SELinux

For our purpose, we do not enable Kdump:

Kdump

We check and set (if needed) the data, time, and timezone.  We also activate the use of the Network Time Protocol (NTP):

NTP

We now create a regular user.  We’ll add more later.

Create User

Clicking on “Use Network Login” gives us more options but we do not use them for now (i.e. leave them with their default values):

Network Login 1

Network Login 2

No additional CDs are used in our installation:

Additional Installation CDs

Finally, the login screen using gdm:

Login Screen Using gdm

First, we escape the login screen by using the key combination: Ctrl-Alt-F1 (Ctrl-Option-Fn-F1 on the MacBook).  We login as root, go to run level 3 (telinit 3), then run Xorg’s auto configuration function:

telinit 3: Kill the X Window Server

We then copy ~/xorg.conf.new to /etc/X11/xorg.conf and edit it, adding the Virtual configuration option as we did in OpenSUSE and Fedora:

Virtual

We then return to run level 5:

Telinit 5

The resulting login screen is now bigger (1680×960 pixels):

Login Screen 1680x960 pixels

Note that using sudo instead of logging in as root all the time is a better habit for security.  But first, you must be root to configure sudo and the user/group account(s) to be granted certain privileges.  Perhaps another article will discuss how to configure sudo.