Common virtualization gotchas when joining an external network

Brad Bird recently ran into a virtualization issue when connecting a virtual machine to an external network. He explains the problem and how to avoid it in the future.

I have been using virtualization since the 90s when VMware workstation was more or less the only easily accessible virtualization player in town.

I now roll out virtualization for my customers in large-scale and provide them with much needed guidance in managing their virtual infrastructure or help them in assessing how to make virtualization work for them.

To continue to educate myself and test various configurations, I've set up my home test lab, which I use to tinker around with various things in a virtual setting, such as adding some scalability or upgrading my router firmware with non-vendor supported  firmware code.

Recently, I ran into an interesting virtualization gotcha while working in my lab setup that I would like to tell you about. Since I regularly monitor public newsgroups and see the number of questions that arise connecting virtual machines to external networks, I know there are many people who might find this post helpful.

I was configuring a virtual machine in my laptop (test and demo) virtual environment, which is essentially Virtual PC 2005 R2 SP1 running in IE7 on my Windows 7 laptop. For more robust virtualization, I boot to an external hard drive loaded with Windows Server 2008 and use Hyper-V.

(For readers of my blog who wonder why I am not using VMware, I will include that in the near future using a Dell D830 laptop and external storage, but I will still manage everything with System Center Virtual Machine Manager 2008 R2. I am a Microsoft virtual machine MVP.)

I had a task -- easy enough to accomplish --that I have done hundreds of times before, which is to connect my virtual machine to the Internet. Just to review: a virtual machine is a computer running within a file. The file is a .vhd file (Microsoft) which is a virtual hard drive. To configure the virtual machine, you use a configuration file (.vmc file). The configuration file contains XML code with all of the settings for the virtual machine.

Configurable settings include:

  • Amount of memory
  • Size and types of hard disk (SCSI or IDE), (dynamic, fixed, differential, pass through)
  • Enabled components like controllers
  • Optical drive (CDROM, DVDROM)
  • Power on/ Power off settings
  • Networking configuration

In particular, to connect to the Internet you must configure your virtual machines to talk to the host computer network card just as Windows 7 does on my laptop.

Since the virtual machines are only files, they can very easily simulate a network and talk to each other without "real" network transfer actually occurring. In other words, the network card or network cable from the host computer is never used.

This is accomplished because the virtualization simulates the network transfer using a type of network called internal. See Figure A.
Click to enlarge.

There are in fact, more types of network than these two but to keep matters simple, I'll stop this explanation here.

Using the internal network type, the virtual machines themselves think they are performing network transfer to transmit data ,but in actual fact, this is more or less like copying files around a local computer.

In my case, I actually needed the virtual machine to talk to the network card to communicate over the Internet so that it could get updates.

The selection for network configuration would be external in my case. This is where things get interesting.

Typically, on a server you may have several network cards. In this case, you would more than likely create several external networks to make use of those cards.

On my laptop, I have a similar situation. I have 1 Ethernet port for "wired" networking and a wireless network card for "wireless" networking. I use my wireless network card 99% of the time.

Now, since I have a laptop, which is a relatively simple setup, I got pinched. The issue was in the configuration of the external network. See Figure B.
Click to enlarge.

The portion after External Network (Intel® 82567LM Gigabit Network Connection) was configured by yours truly in order to be more clear with my configuration by listing the network card name.

This name is just a string value and, in fact, the external network may be configured to use any network card installed in the computer. See Figure C.

Where I got caught was by not changing the network card which was being used by the external network, and possibly changing the name. This is a common issue, which I myself recently fell prey to.

The other common issue that comes up has to do with DHCP.

The configuration of the network card often includes DHCP or lack of it (static IP address). If you use the host computer network card and need DHCP, however; the way your network card receives its IP information is how your virtual machine will receive it. If all you need is basic IP information to communicate on the network, this is often fine. But you are likely to require more granular control when you are participating in a corporate network.

Just like physical desktop computers and network devices require controlled access to communication on the network, likewise virtual machines share these challenges.

The default for IP networking in Windows operating systems -- at least since Windows 95 -- is to use DHCP. In virtualization, if you choose to obtain your DHCP information from a server, you need do nothing different than you normally would for a physical machine.

In the case where you would be using DHCP, but do not have a DHCP server, and still require granular control over IP network configuration information received by the virtual machines, you can use a virtual DHCP server on any network type for this. See Figure D.

This will get around the challenge of requiring control of DHCP information without needing to configure a separate server for the purpose.

Have you run into this issue before? Do you have similar virtualization experiences to share?

By Brad Bird

Brad Bird is a lead technical consultant and MCT certified trainer based in Ottawa, ON. He works with large organizations, helping them architect, implement, configure, and customize System Center technologies, integrating them into their business pr...