VMware Networking: Configuring and troubleshooting a vNetwork DvSwitch

I will explain how to set up a distributed vNetwork (DVN) with VMware, and how to troubleshoot your vNetwork if problems occur. In part one, I discussed the basics of virtual networks, as well as how to create and configure a standard vNetwork.

Distributed virtual networks use a distributed virtual switch (DvSwitch) to manage data transmission between virtual machines and enable guest systems to connect to physical networks. As I explained in the last post, a DvSwitch works like a global switch; all of the hosts in a datacenter can connect to a single distributed switch. A DvSwitch also enables the use of private virtual local area networks (PVLANs), which divide VLAN domains into smaller sub-domains, enabling multiple hosts to use the same address space, but exist separately, or isolated, from one another.

Like standard virtual switches, distributed virtual switches provide virtual uplinks called distributed virtual uplinks (dvUplinks). Uplinks represent physical network adapters. When creating a DvSwitch, the virtualization platform finds the maximum number of uplinks associated with a host and uses that number as a basis when setting up the dvUplinks on the switch.

DvSwitches offer more ports than do standard virtual switches; the former offers up to 6,000, compared to the latter, which provides up to 4,088. A maximum of 64 hosts can connect to a single DvSwitch and up to 16 distributed switches can be implemented per host.

DvSwitches are stored to the VMkernel, but the settings linked to the DvSwitch are contained in the vCenter database. Therefore, to create a distributed switch in VMware, you must have vCenter installed.

Creating a Distributed Virtual Switch

1. In vCenter, select “Home” and then “Networking.” Click the datacenter on which the host or hosts reside.

2. Select from the toolbar the icon to launch the Create vNetwork Distributed Switch wizard. Name the vNetwork. Click “Next.”

3. Select each host to associate with the DvSwitch, and then select which network adapters to use with each ESX/ESXi host. Choose multiple network adapters to create uplink groups and provide load balancing and fault tolerance to a host. Make sure to select the correct network adapters during the creation process, as reassigning the adapters is not a simple process. Click “Next.”

4. Click “Finish” to create the DvSwitch in vCenter.

Configuring DvSwitches and Port Groups

DvSwitches and vSwitches share most of the same options, but distributed switches offer a little bit more control over the operation of the vNetwork. To access the settings, right-click the virtual switch and then select “Edit Settings” from the context menu.

On the General tab are options to change the name of the switch and the number of dvUplinks connected to the vNetwork. On the Advanced tab are options to increase or decrease the maximum transmission unit (MTU), which limits packet size, and enable Cisco Discovery Protocol. In later versions of vSphere, you can also set up features like NetFlow, which analyzes network communications transmitted between virtual machines and physical networks; or port mirroring, which copies packets from one port to another for monitoring purposes.

To configure the port group, right-click it and then click “Edit Settings.” Most of the options match those described in the previous article, with a few exceptions:

General

Static Binding: Adheres a virtual machine to a port on the DvSwitch that remains active even when the machine is powered off

Dynamic Binding: Assigns a port to a virtual machine at the time the machine is powered on

Ephemeral: Allocates a port to a virtual machine when powered on. If the machine reboots, it loses its old port and is assigned a new one

Advanced

Override Port Policies: Overrides the settings associated with the dvUplinks

Live Port Moving: Transfer stand-alone port groups to distributed port groups, assigning settings associated with distributed port group to the stand-alone group

Configure Reset at Disconnect: Port settings are reset when a port is disconnected from a virtual machine

Port Name Format: Changes the naming convention of a port group

Troubleshooting a vSwitch or DvSwitch

Under ideal circumstances, the vNetwork will work as intended after creating and configuring the virtual switches and port groups — but certain settings can interfere with how the virtual network functions.

A virtual machine uses a port group to communicate across a network. Port groups are associated with a parent switch, so if a machine’s virtual network adapter is not assigned the correct port group, it might not link to the correct distributed or standard switch, either. Furthermore, port group names are case-sensitive, so a group named “Test,” for example, is not the same as a group named “test.”

To confirm that a virtual machine is connected to the correct port group, right-click the virtual machine and then select “Edit Settings” from the context menu. Select the appropriate port group from the drop-down menu.

While in Virtual Machine Properties, also confirm that “Connected” and “Connect at Power On” are checked under the Device Status heading. Click “OK.” Restart the virtual machine or network services if the machine has not been assigned a static IP.

If the settings for the virtual machine are correct, move on to checking the vNetwork settings for the host. Click the Configuration tab after selecting the appropriate ESX/ESXi host and then select the Networking link.

Choose “Virtual Switch” or “Distributed Virtual Switch” from the menu. Click the call-out icon for the correct switch or port group and review the settings shown in the dialog box to confirm that the network configuration is correct.

If you detected a problem with the settings, click the Properties link to make changes to the vSwitch. If you’re working with a distributed switch, follow the instructions in the above sections to change the switch’s properties. To learn more about the options available on these screens, go to the first part of this series and view “Configuring Port vSwitches and Port Groups.”

If you’re working with a vSwitch, make sure that the port group is using the original name assigned to it upon creation. If you’ve changed the name of the port group, you must edit the properties of every virtual machine originally connected to it and select the new name from the drop-down menu under Network Connection.

If your switches and port groups are all in order, the next things to check are the network adapters. If working with a standard switch, select the Network Adapters tab from the vSwitch properties window. If working with a DvSwitch, select “Manage Physical Adapters” from the Networking screen.

Confirm that the adapter is using the correct speed and duplex. If the adapter settings don’t match that of a network component or client, performance or connectivity issues can occur. Click “Edit” to change the adapter settings

VMware Networking: Configuring and troubleshooting a vNetwork

The term vNetwork refers to the technologies that VMware vSphere utilizes to integrate networking and input/output functions on an ESX/ESXi host. vSphere includes a number of features and enhancements to provide administrators thorough control over networking processes and make management of these processes simpler.

Implementing a vNetwork in ESX or ESXi is essential for enabling virtual machines to communicate with one another within a networking environment — but establishing a vNetwork on a host can be a difficult and complicated process if you don’t understand how virtual networking works in vSphere.

A virtual network is made up of virtual machines that run on a single, physical machine and transmit data to and from one another. In vSphere, a virtual switch is called a vSwitch. Virtual machines connect to the virtual ports that make up the vSwitch to create a vNetwork. The vSwitch then routes network traffic between the connected virtual machines. vSwitches can also use physical network adapters, or uplink adapters, to connect to a physical switch and associate the virtual network with a physical network.

In vSphere 4, VMware introduced an enhancement to vNetworks: the distributed virtual switch, or DvSwitch. A DvSwitch acts like a global switch, enabling administrators to associate a single switch with all ESX or ESXi hosts in a datacenter, rather than configure a vSwitch for each individual host.

vSphere separates vSwitches and DvSwitches into smaller groups called port groups. VMware uses port groups to connect virtual machines to a switch and define settings like traffic shaping, NIC teaming, load balancing, and other parameters.

Creating Standard Switches

In vSphere, vSwitches can be mapped to one network adapter or to multiple network adapters. vSwitches that have no associated network adapters can also be implemented as well.

A standard switch that has no associated adapters is called an internal vSwitch. Virtual machines connected to an internal vSwitch cannot communicate with other virtual machines outside of the host. These switches can be used to test virtual machines before mapping them to a production network. A vSwitch that is associated with two or more adapters is called a teamed vSwitch; these switches provide an added layer of protection to a network and are used for fault tolerance and load balancing.

A vSwitch starts out with 56 ports, by default, but can be configured to use up to 4,088 ports, and up to 20 network adapters can be associated with a host.

To create a standard switch in vSphere, follow the instructions below:

1. In vSphere, select the ESX or ESXi host. Click “Configuration.” Select “Networking” from the Hardware box. Click “Add Networking” to run the Add Network Wizard.

2. Select “Virtual Machine” and then click “Next.”

3. Select each network adapter to associate with the vSwitch. To create an internal vSwitch, make sure that all network adapters are deselected.

4. Create a unique name for the port group. Names are case-sensitive. (A couple things to keep mind when naming port groups: one, if the names aren’t consistent from host to host, problems will occur when migrating virtual machines or using VMotion; two, while it’s possible to rename a port group after-the-fact, virtual machines that were connected to that port group will disassociate with the switch. Therefore, to avoid potential complications, it’s best to keep track of port group names and follow a standardized naming convention.)

5. Click “Finish” to create a standard vNetwork.

Configuring vSwitches and Port Groups

After creating a vNetwork in vSphere, you can modify the vSwitch to add additional ports and change network parameters.

Add Port Groups

As I mentioned in “Creating Standard Switches,” vSwitches start out with 56 ports, but administrators can increase the port number up to 4,088. Increasing the number of ports per vSwitch is not recommended unless the operating environment requires it, as the ESX/ESXi host must be restarted after the change, and upping the port number requires additional overhead that will lead to wasted resources.

To increase the number of ports per switch:

1. Select the host and then click the Configuration tab. Click “Networking” from the Hardware box.

2. Select the Properties link. Click “vSwitch.” Click “Edit.”

3. Choose from the drop-down menu the number of ports to use with the standard switch. Click “OK.”

Set Network Policies

You can change the parameters of a vSwitch to apply global policies to the vNetwork. Port groups feature options similar to those available to switches and can be used to add greater flexibility to a virtual network, as the settings associated with the port group can act as exceptions to the global policies. You can access the network settings using the same method as described in the section above.

I’ll provide a brief overview of the options you’ll find on each tab:

Security

Promiscuous Mode: Enables a network adapter to retrieve and read all network traffic. Used for packet sniffing to troubleshoot and diagnose network issues.

MAC Address Changes: Allows the virtual MAC address associated with a virtual machine to be changed. Used to create cluster addresses for services like Network Load Balancing, used by Windows Server.

Forged Transmits: Enables a virtual machine to transmit network traffic even if the MAC address on the guest operating system doesn’t match the MAC address stored to the .vmx file (the file that holds the virtual machine’s configuration information).

Traffic Shaping

Traffic shaping is used to control bandwidth on a vNetwork. Traffic shaping focuses on outbound traffic sent from a virtual machine to the physical network; it doesn’t interfere with inbound traffic. The vast majority of administrators will never need to use this feature, particularly because traffic shaping in the vSphere environment is not dynamic and can hinder network performance.

NIC Teaming

NIC Teaming is used for fault tolerance; you can configure standby adapters to take over when the primary adapter fails.

Load Balancing: Configures how outgoing traffic is handled across multiple network adapters in a teamed vSwitch.

Network Failover Detection: Specifies how the host detects network failure.

Notify Switches: Tells the physical switches to route network traffic from virtual machines to different physical network adapters.

Failback: Specifies how the failed adapter should operate if it comes online again.

That’s it for configuring standard switches in vSphere. In part two, I’ll explain how to set up a vNetwork that runs on a distributed switch, and how to troubleshoot your vNetwork if problems occur.

Four mistakes that can kill virtual machine performance

Screensavers, managing from the console, real-time security scans and certain Windows Server power options can all undermine virtual machine performance. Here's how to avoid VM performance killers.

Ah, how I love the easy ones. In many cases, the easiest mistakes cause some of the biggest performance problems in virtualization environments. In my consulting, I've seen a few major errors that are worth sharing. Some of these may seem obvious, but consider checking your settings. You may be surprised at what you find.

Easy Mistake 1: Virtual machine screensavers

Screensavers are an absolute requirement for desktops in the hallways of our brick-and-mortar offices. They ensure that a user who walks away from his computer returns to one that has been secured against prying eyes. Screensavers can also provide protection in data centers. If screensavers on servers activate and lock the console after a few minutes of inactivity, they can protect that environment from an intruder who gains physical access.

But screensavers are a quiet consumer of processor resources. No matter how insignificant that screensaver seems, the processor power required to draw the pipes crawling across the screen or to scroll your favorite company slogan consume a percentage points of overall processor power. While that might not seem like much, consolidated virtual environments might have 10 or 15 virtual machines (VMs) running on a single virtual host. These percentage points add up when they are multiplied by the number of VMs. Even worse, if your environment uses hosted desktops through a virtual desktop implementation, this practice likely costs even more.

So turn them off. Remember that many environments enforce screensavers through group policies, which may mean an exclusion from existing group and corporate security policies.

Easy Mistake 2: Managing from the console

This second mistake is one of my favorites, because it is common among IT administrators everywhere. Do you manage your infrastructure components by remoting and logging into their individual servers? Do you run the Exchange Management Console from your Exchange server? Do you check domain name server (DNS) settings from the server's console? Do you manage Active Directory by remoting your domain controllers?

If you are, stop.

As with screensavers, this practice is a big no-no in virtualized environments because of the level of resources required to create and maintain an instance of the Explorer shell. Just logging into a virtual machine is hard on that VM's processor utilization. The process of creating a shell for the console can spike processor utilization during the login and logout process. Actually using any of the consoles on that server further consumes valuable resources. Logging in and accomplishing activity on your VMs' desktops increases the amount of memory they consume.

Microsoft provides the Remote Systems Administration Toolkit, PowerShell and VBScript, as well as many other tools for efficient virtual machine management. All these lightweight tools require much less VM capacity than a traditional login. So use them, and avoid wasting processing power and memory like an amateur.

Easy Mistake 3: Antivirus and anti-malware scanning of VM disk files

Your corporate security policy might not allow for the exclusion of Virtual Hard Disk or Virtual Machine Disk Format (VMDK) files from antivirus and anti-malware scans. But be aware that the real-time scans of such products can substantially reduce the overall performance of these files -- and, thus, their virtual machines. Since a VM's processing is highly dependent on its disk subsystem, any extra activities that slowdown that process slow it down as well.

That's not to say that VM disk files shouldn't be subject to security scanning. Scheduled scans of such files can ensure that they don't get infected, without the processing overhead of real-time scans. Also, some of today's more advanced scanning products are beginning to incorporate virtualization awareness to reduce their overall impact. If your security policy will allow it -- or if you can bribe your security officer to look the other way -- definitely consider excluding these files from your real-time scans.

Easy Mistake 4: Windows Server's power options

At conferences around the country, I've encountered the final mistake repeatedly. The default power option of Windows Server 2008 upon installation is set to "Balanced." Of the three options available -- Balanced, Power Saver and High-Performance -- this is the second of the three in terms of overall system performance. You might save a few dollars on energy, but at the cost of wasting some of the server's processing power. Resetting the radio button to the high-performance option has a noticeable effect on how well VMs will perform.

Group policy is probably the easiest way to do so. If you create a new policy and navigate to "Computer Configuration > Policies > Administrative Templates > System > Power Management," look for the policy called "Select an Active Power Plan." Configuring this policy across your server infrastructure ensures that you always run with highest performance.

If you've got an easy mistake that I've missed, I've love to hear about it. Drop by e-mail @ Ismail_syscon@yahoo.com and tell me about your own fixes for easy virtualization mistakes!

Tips for Troubleshooting VMware vSphere

Performance Monitoring Tools:-

The vSphere performance charts allow you to display useful information when you are connected either to the ESXi host directly or to the vCenter Server. The performance charts can provide a lot of useful information, even if they do not provide all of the counters that you will find with esxtop.

The host based tool esxtop provides for some inherent advantages over the vSphere performance charts and third-party tools when it comes to performance analysis. One big advantage is that esxtop incurs very little overhead on the ESXi host. Since, esxtop is lightweight and the footprint is small, it is an excellent tool to measure performance. If you have a situation where poor performance is affecting connectivity to the host, you can use resxtop (remote esxtop). Another advantage of using esxtop is you can export the data into a comma delimited file.

If You Suspect a Network Performance Issue, Check Some of the Following Metrics

If the droppedRx (receive) is greater than 0 for a host, look at the CPU utilization. Check metrics such as CPU overhead and high CPU utilization, which can cause the VM to be too busy to take on new packets or delays in receiving the packets. A possible solution is to increase CPU reservations for the VM or check the application to see if it supports adding more vCPUs.

If the droppedTx (transmit) is greater than 0, this usually means congestion at the physical layer. When a VM is transmitting packets, the packets get queued in the buffer of the virtual switch port until the packets are transmitted on the physical nic. To prevent the dropping of transmit packets, look for ways to increase the physical network capabilities, such as adding more nics or adding 10 GB Ethernet.

Make sure you have the correct network device driver installed on the VM. By default, if VMware tools is not installed or running, the Vlance network adapter will be used. Vlance is a 10Mbps NIC, which is great for older 32-bit guest operating systems but not so useful running in a 1 GB Ethernet network.

Metrics to Check for a Possible Storage Problem

esxtop/resxtop, which comes with ESXi 5, is an excellent tool to measure performance. Some of the more significant statistics are commands queued. To check these metrics, open a vSphere Management Assistant (vMA) console and start resxtop. Type d to enter the Storage Adapter screen. Type f to select the fields that you want to view. The fields to view should be A (adapter name), F (queue stats), and K (error stats).

There are other esxtop fields that can be utilized to indicate that there could be a storage problem. To identify disk-related performance problems look at throughput and latency.

Throughput fields in esxtop (READS/s + WRITES/s = I/O operations/second (IOPS):READS/s – Number of disk reads per secondWRITES/s – Number of disk writes per second

Latency fields in esxtop:

DAVG – Average delay from the adapter to the target in ms, value greater than 10 – 15 milliseconds indicates that the storage might be slow or overutilizedKAVG – Average delay from the vmkernel to the adapter in ms, value greater than 4 milliseconds indicates the VMs are attempting to send more data to storage than the storage can handle

GAVG – Average delay for the guest, which will be DAVG + KAVG = GAVG

Log Files to View in vSphere 5

All log messages are now generated by syslog, and messages can now be logged on either local and one or more remote log servers, or both. In addition, a given log server can log messages from more than one ESXi host.

To view ESXi system logs, in the vSphere Client menu bar, select View > Administration > System Logs.

/var/log/auth.log             ESXi Shell authentication success and failure

/var/log/dhclient.log      DHCP client service

/var/log/esxupdate.log ESXi patches and updates log

/var/log/hostd.log           Host management service logs

/var/log/shell.log             ESXi Shell usage, including enable/disable and every command entered

/var/log/sysboot.log      VMkernel startup and module loading

/var/log/syslog.log          Management service initialization, watchdogs, scheduled tasks, DCUI

/var/log/usb.log               USB device arbitration events, such as discovery and pass-through to VM

/var/log/vob.log               VMkernel Observation events, similar to vob.component.event

/var/log/vmkernel.log   Core VMkernel logs (devices, storagage/network device/driver events, and VM

startup.

/var/log/vmkwarning.log             VMkernel Warning and Alert log messages.

/var/log/vmksummary.log           ESXi startup/shutdown, uptime, VMs running, and service resource consumption

Logs from vCenter Server Components on ESXi 5

/var/log/vpxa.log             vCenter vpxa agent logs

/var/log/fdm.log              High Availability logs, produced by the Fault Domain Manager (FDM) service

Last-Level Cache (LLC) Performance Issue

The ESXi CPU scheduler, by default, tries to place the vCPUs of a Symmetric Multiprocessor (SMP) VM into as much Last-Level Cache (LLC) as possible. ESXi, by default, is going to place as many vCPUs of a SMP VM into as many of the L LLCs as possible. Therefore, ESXi is going to attempt to spread out the cycle, and find space to run the workload. If you are running a very

CPU-intensive workload, you might benefit from setting up a clone of the application VM. Then turn on the LLC setting below and test the cloned application to see if there is a performance increase. If the modification works, the CPU scheduler is going to attempt to consolidate the vSMP VM into one CPU package, thus one shared LLC pool. Therefore, the CPU scheduler will now attempt to run the VM on the same package more than it would otherwise.

Using the vSphere client:

Power off the VM.

Right click the VM and select Edit Settings.

Select the Options tab.

Under Advanced, click General, and on the right click the configuration Parameters button.

Click Add Row.

Add sched.cpu.vsmpConsolidate set to true.

Power on the VM.

From the command line interface:

Power off the VM.

Add the following line into the configuration file (.vmx) of the VM.

sched.cpu.vsmpConsolidate = “true”.

Power on the VM.

Cannot Migrate a VM Using VMotion

Check the ESX(i) hosts to make sure all of the requirements have been met. Then check to make sure that the CPU is compatible. If the VM is running a 64-bit operating system, the problem might be that the source machine has Intel Virtualization Technology (VT) enabled in the BIOS, and the destination host does not have VT enabled in the BIOS. If this is the case, you will have to make a change in the BIOS so both hosts match. Also, both hosts must have a VMkernel port on the same LAN. The IP address and subnet mask should match the network configuration for VMKernel gateway.

You could run from command line:

# vmkping <Destination_IP _address> to test the VMkernel TCP/IP stack.

Any VLAN settings should match the VLAN configuration of the local LAN. VMkernel ports should have the check box VMotion enabled. There should be no router separating the hosts.

Check the VMs to make sure all of the requirements have been met.

Check that there are no local devices connected to the VM.

Check CD-ROM mappings to any ISO file on local storage, Floppy, SCSI, USB, CPU affinity, .vswp files stored on local storage.

Check that the VM has enough CPU and memory resources on the destination host

Exploring the vSphere Web Client and Configuring Active Directory Permissions

Install vCenter Server 5.5 (simple installation )

installing and configuring esxi 5.5 Video

installing and configuring Esxi 5.5

First things first we are going to install ESXi Server 5.5.0. This is the baremetal hypervisor that will run our VMs and may be one of several servers you wish to build into a cluster managed by vCenter server to provide HA, DRS and vMotion features for VMs.

The ESXi server installation is straightforward, at this initial stage all we need to do is get the hypervisor installed, give it an IP address and password before proceeding with the various steps for the vCenter Server install.

1. Check the server hardware you are installing ESXi 5.5 onto is supported and on the VMware HCL.

2. Login to the VMware license portal to check/upgrade/buy your vSphere licenses.

3. Read the ESXi Setup Guide to ensure you understand the pre-requisites.

4. Download the VMware ESXi 5.5 U1 ISO file from the VMware download area.

5. Burn the ESXi 5.5 ISO to a CD.

6. Disconnect all Fibre Channel connections (if any) and boot the server from the CD.

7. Boot the server from the CD and Select "ESXi-5.5.0-20140302001-Standard-Installer"

8. When ready to install press "Enter"

9. Read and accept the license agreement, press F11 to accept.

10. Select the correct storage device to install ESXi on and press "Enter"

NOTE: Ensure it is not a fiber channel (FC) VMFS datastore or RDM! Make sure your fiber cables or disconnected or zoning excludes this host during the install/upgrade.

There is a tendency for local storage devices to show as remote (as in the case below). If this happens ensure it is local storage and not a fiber channel LUN.

11. Select the keyboard layout and press Enter.        

12. Enter a secure password for the "root" account, store it in a safe place and Press Enter.

13. Press F11 to start installing ESXi.

Note: The install doesn't take too long, only just enough time to make a cup of tea!

:) 

14. Once the installation is complete press Enter to reboot the ESXi server.

Your CD will be ejected at this point.

15. Once the ESXi server has booted it will receive a DHCP lease (if applicable) you can now manage this with the vSphere client or continue to set a static IP for management (recommended)

16. Hit F2 and enter your root username and password.

17. Select "Configure management network"

18. Select "IP Configuration"

19. Change to "Static IP"

20. Enter your IP address, mask and gateway and hit Enter.

It might also be advantageous to disable IPV6 if you are not using it, which is enabled by default now.

21. Press escape [ESC] to get back to the main menu.

22. You will be asked "Apply changes and restart management network?” say yes [Y]

Note: You can set you VLAN ID in this section too if you need.

23. Job done! You will now see you static IP address is set and you can now manage this with the vSphere client.

24. You should also now create A records on your DNS server for your ESXi servers.

E.g. esxi-3.vmadmin.co.in   A  192.168.1.210

happy learning 

Ismail Baig 

How to Setup & Configure DNS Server on Windows 2008 R2 Server Step by Step

The Domain Name System (DNS) is a hierarchical distributed naming system for computers, services, or any resource connected to the Internet or a private network. It associates various information with domain names assigned to each of the participating entities.

Most importantly, it translates domain names meaningful to humans into the numerical identifiers associated with networking equipment for the purpose of locating and addressing these devices worldwide.

However, most Windows administrators still rely on the Windows Internet Name Service (WINS) for name resolution on local area networks and some have little or no experience with DNS.  We’ll explain how to install, configure, and troubleshoot a Windows Server 2008 DNS server.

Installation:

Step 1: Install a DNS server from the Control Panel, follow these steps:

   Go to   Start —> Control Panel —> Administrative Tools —> Server Manager.

   Expand and click Roles

   Click on Add Roles

Step 2: The new window will open with the list of roles available to install. Select DNS server and Click Next.

Step 3: Click next on the introduction windows. In the last window click on install. It will start installation, the following window shows the progress of installation.

Configuring DNS:

After installing DNS, you have to go  Start —>  All Programs —>  Administrative Tools —>  DNS  for managing DNS server.

Whenever  configuring your DNS server, you must be know about  following concepts:

• Forward lookup zone
• Reverse lookup zone
• Zone types

A forward lookup zone is helps to  resolve host names to IP addresses. A reverse lookup zone allows a DNS server to discover the DNS name of the host. Basically, it is the exact opposite of a forward lookup zone. A reverse lookup zone is not required, but it is easy to configure and will allow for your Windows Server 2008 Server to have full DNS functionality.

When selecting a DNS zone type, you have the following options: Active Directory (AD) Integrated, Standard Primary, and Standard Secondary. AD Integrated stores the database information in AD and allows for secure updates to the database file. This option will appear only if AD is configured. If it is configured and you select this option, AD will store and replicate your zone files.

A Standard Primary zone stores the database in a text file. This text file can be shared with other DNS servers that store their information in a text file. Finally, a Standard Secondary zone simply creates a copy of the existing database from another DNS server. This is primarily used for load balancing.

Step 1: Right Click on the name of the server in the DNS management console, Select on the Configure DNS server.

Step 2: Click on Create forward and reverse lookup zone, then click next.

Step 3: Click on the Yes, create the forward lookup zone now on the forward lookup zone window.

Step 4: Click on the desired zone that you want to create, in this case Primary Zone

Step 5: Type the Name of the Zone and click Next.

Step 6: Click Next on the Zone File Name.

Step 7: Select the Allow both nonsecure and Secure dynamic updates and click Next to Continue.

Step 8: Select Yes, I want to create reverse lookup zone now, Click Next to continue.

Step 10: Select Primary Zone in Zone creating Window.

Step 11: Choose whether you want to create IPv4 or IPv6 reverse lookup zone.( in  mycase IPv4 Reverse lookup zone)

Step 12: Type you network ID in the following window.

Step 13: Click next on the Reverse lookup Zone file name window.

Step 14: Select the Allow both non-secure and secure dynamic updates and click Next to Continue.

Step 15: Select No, i should not forward queries, then click Next.

Step 16: Click finish on the final window.