VMware vSphere Lab: Virtual Edition – Part 5

This is the fifth post in a series outlining how to set up your own little virtualized Virtual vSphere Lab, if you missed part one, part two, part three, or part four, be sure to check them out first!

Ideally we would now install Microsoft Active Directory Domain Services (AD DS) on the Windows Server 2008 R2 VM we created in part four, but since VMware vCenter Server 4.1 also installs AD LDS (previously known as Active Directory Application Mode (ADAM)) it can not be installed on a AD Domain Controller.

This means that we either need to install a second VM with Windows Server 2008 R2 on, and install and configure Active Directory Domain Services (AD DS) on it, or run without an available Active Directory domain. Running a second Windows Server 2008 R2 install will consume a lot of resources, especially memory, which might not be available to you in your lab environment. For now, I’ve decided to go on without it.

Some advanced features, that require Active Directory, will therefore not be available to us in the current lab setup.

These features include

  • Active Directory Integration
  • Linked Mode Virtual Center Installs
  • Guided Consolidation

There are also a couple of other things that we need to consider when deciding to not to set up a domain for the lab. The most important thing is that this means that we won’t automatically have any name resolution services available. Since features like High Availability (HA) is very dependent on DNS, this is the route I decided to go. Another, but smaller, caveat is that we will have to use locally created users when connecting to vCenter, but that is not a big deal in such a small environment.

In addition to DNS, it’s a good idea to install DHCP as well, as the DHCP server in Windows Server 2008 R2 can register your DHCP clients in DNS for you, and thus eliminate the need to provide static IPs to your ESXi hosts or VMs.

Lets get down to business, the first order of the day;

Isolating the server network and assigning static IP

Installing DHCP is pretty straight forward, you add the role and configure it, and you’re done. In this case, however, there are a few other things that need to be done before we setup a DHCP server and let it run wild in your environment. Setting up a “rouge” DHCP server has the potential to wreck havoc in your network, so you need to make sure there is no spillage of IP address configuration to your live network. To make sure this doesn’t happen, we need to change some networking settings for your VMs and isolate them in their own environment, before we install anything else.

To do this open VMware Workstation, and find your lab-esxi1 VM.

Select “Edit virtual machine settings

In the “Virtual Machine Settings” window, find “Network Adapter” and change the value from “NAT” to “Host-only

Click “OK“. Make sure that “Network Adapter” is set to “Host-only“.

Repeat this step for lab-esxi2, and lab-vc1 as well.

Now, your VMs are isolated from your live network, but can still interact with each other inside their own little bubble of fuzzy IP-goodness.

Assigning static IP

Power up the lab-vc1 Windows Server VM, and log on. Before we install DHCP, we need to assign a static IP. In order to be good IP citizens, we should chose from one of the available private pools of IP adresses for our lab setup. RFC1918 defines a couple of IP blocks we can use, and in this case I decided to go with the 192.168.1.x range, and use the following setup:

Hostname IP Subnet mask Gateway

To assign this static IP adress to the server, click on “Configure networking“.

This opens the “Network Connections” window, where you will see your “Local Area Connection” interface.

Right-click the “Local Area Connection” interface and select “Properties

Highlight “Internet Protocol Version 4 (TCP/IPv4)“, and select “Properties“.

Select “User the following IP address:” and fill out the information from the table above (We do not need a default gateway in this isolated network, so leave that blank).

Since we are installing DNS on the same server in a little while, we might as well put the server IP ( in both preferred and alternate DNS server boxes right now as well.

Click “OK” and then “Close“.
We have now assigned a static IP to the server, and can continue with installing DHCP.

Installing DHCP

Finally, we can get on with installing the DHCP service for our lab. To do this, start Server Manager which is available on the right hand side of your “Start” button.

Click on “Roles” and then on “Add Roles” . This starts the “Add Roles Wizard“. Click on “Next“, and the available server roles are presented.

Find DHCP Server, and select it.

Click “Next” and you’ll get presented with a nice little screen that explains DHCP. We’ll skip that pretty quickly, and click “Next” again. The next thing in line, is a screen where you select which network adapter the DHCP service should bind to.

Since we only have one network interface in this particular server, we’ll just accept the defaults and click “Next” again. The “Specify IPv4 DNS Server Server Settings” appear, and we need to fill out the “Parent Domain” name. Since this is our Virtual vSphere Lab, I named it vLab.

Fill out the required information and click on “Next“. We don’t need WINS based name resolution in our lab setup, so we’ll leave the default of “WINS is not required for applications on this network” as is, and yet again click “Next

Now, we need to configure our DHCP scope, to let the DHCP server know which IP addresses it is responsible for and provides the DHCP client with.

Click on the “Add” button

This is where we actually get to do something, instead of just clicking along the whole time. Fill out the following information:

DHCP Configuration
Scope name vLabScope
Starting IP address
Ending IP adress
Subnet Type Wired (Lease duration will be 8 days)
Subnet mask
Default gateway (optional)

It should look like this:

Click “OK” and verify that everything looks like it should

Click “Next” and select “Disable DHCPv6 stateless mode for this server“, there is no need for IPv6 DHCP in our lab at the moment.

and click “Next” again.

Review the settings you have configured, and click on “Install” to actually get the install going.

Click “Close” and thats it, DHCP has now been installed and configured! Well done!

Installing DNS

If Server Manager is still running, click on “Add Roles“. If not, start Server Manager first.

Click on “Roles” and then on “Add Roles” . This starts the “Add Roles Wizard“. Click on “Next“,

Click “Next” and in the “Select Server Roles” windows, select “DNS Server

Review the “Introduction to DNS Server” screen, before continuing by clicking on “Next“.

Click on “Install” and the install continues.

Click “Close” to end the installation procedure for DNS Server.

Next up, configuring DNS. Navigate to Start -> Administrative Tools -> DNS

And that should be it! We now have working DHCP and DNS servers in our little lab network, ready to provide your ESXi hosts with the information they need!

In part six, I’ll be going through installing VMware vCenter Server 4.1. Stay tuned!

Now that

7 thoughts on “VMware vSphere Lab: Virtual Edition – Part 5

  1. great post, l will be following your guide in the setup, before l come to a standstill on part 5, can you please let us know when Part 6 is available?

  2. Thanks for this!! Helps tons. Great work. I’ve only noticed one glitch and that is that R2 needs a different Alternate DNS address during setup. It rejects the ip if it is the same. Small matter.

    Thanks again,


    1. @LouFarr: That’s a good point. I’ll have to correct that, earlier versions didn’t complain and basically setting both to the same would effectively double the time-out period.

  3. How do you get your Virtual host to resolve?

    For example after I set up a domain controller, DNS, and begin joining servers to the domain they were unable to resolve there names. (nslookup)…

    Can you test this as well. I currently use a secondary DNS server to get out (for internet). But it doesn’t resolve any server names… let alone locate the name server…

  4. I believe it has to do with the networking I am using… perhaps if I used bridged it would go away. I think it has to do with the NAT option I am using. It uses the VMware DNS service (VMware workstation) which really doesn’t resolve anything. I just though that I should still be able to resolve internally..

Leave a Reply