How To Create A Network Test Lab With VMware
Let’s say that you want to do some testing of network applications using VMware. This is the perfect use for a VMware’s virtualization technology. By default, most people connect their virtual machines to the bridged (VMnet0) network. This is great for connecting to the Internet and downloading patches or registering the OS. However, once you have done that, many times, you want to connect two or more virtual machines together to create a private network lab environment. Let’s talk about how to do that.
Introduction to VMware Networks
Before we talk about changing the network of a virtual host, let’s learn about the different VMware networks that are available. By default there are three virtual networks created on a VMware server. They are: VMnet0 – Bridged VMnet1 – Host-only VMnet8 – NAT
To configure VMware networks, inside the VMware server management interface, go to Host à Virtual Network Settings, like this:
Once inside the virtual network settings, you will see a summary of the virtual networks, like this:
Here you can see the three different virtual networks that I talked about above. Inside this Virtual Network Editor, as it is called, is where you make all VMware network changes. The configuration of these virtual networks and how they match up with the virtual machines can get complex. Now that we know what virtual networks are available, let’s talk about how to change from the bridged (VMnet0) network to a network that can be shared by our two lab machines.
Changing the Network on a VM
We want to modify our two Windows XP machines to be on the same private host network so that we can have a virtual lab environment. Keep in mind that we still want to use DHCP for host IP address assignment. Fortunately, VMware offers a built in DHCP server to assign IP addresses to these virtual machines who will now be on their own network. This DHCP server is enabled by default and, once the virtual machines are on the proper VMnet, the DHCP server will provide them an IP address.
To change from the bridged (VMnet0) network to the host-only (VMnet1) network, first, make sure that both machines are powered off. You cannot modify the network configuration if they are started or suspended.
Next, double-click on the Ethernet adaptor in each machine. Currently, you should see that it is set to Bridged.
You will now have the network adaptor configuration window below. Click on the Host-only adaptor.
Now click OK to save these changes.
Next, power on both machines. Once booted, both these machines should only be able to communicate with one another and only each other. No other machines on your internal network or any other virtual machines should be able to communicate with these virtual machines (unless their network adaptor is also set to VMnet1/Host-only). You can verify this by opening up the CMD prompt on both machines and running IPCONFIG /ALL. You should see something like this:
Notice in the output above how each machine has an IP address on the same network. Machine 1 is 192.168.1.129. Machine 2 is 192.168.1.128. These IP addresses were assigned by the DHCP server at 192.168.1.254. That is actually the VMware built-in DHCP server for the VMnet1 network.
On the output from Machine 2, notice that I was able to ping 192.168.1.129 successfully. This shows that I can ping Machine 1 in my net lab network.
In this article, we learned the basics of VMware Networks and how to put two machines on a private network, creating a lab environment. Now that you have these two machines on their private network, you no longer have to worry about making some change that might affect your production network. You can feel free to test things like DNS servers, new Windows domain controllers, or have hosts that have the same names as other hosts on your production networks.
Got a question? Post it on our VMware Forums!
More in VMware
Big Announcements at AWS re:Invent 2021
Dec 2, 2021 | Michael Otey
Amazon Announces the General Availability of VMware Cloud on AWS Outposts
Oct 12, 2021 | Michael Otey
VMworld 2020 – Announcements
Oct 5, 2020 | Michael Otey
VMware Embraces Kubernetes for App Modernization
Mar 12, 2020 | Michael Otey
VMworld 2019 Day 2 – VMware Demos Project Pacific, Tanzu Missional Control and More
Aug 28, 2019 | Michael Otey
VMware Gets Behind Kubernetes to Build-Run-Manage in the Cloud
Aug 27, 2019 | Michael Otey
Most popular on petri