Tech Line

Virtual PC MAC Address Malfunction

Here's how to prevent duplicate Virtual PCs from using the same MAC address.

Chris: I have a 150 PCs running Windows XP across three VLANs connecting to Active Directory on a Windows 2003 server. Each PC runs Microsoft Virtual PC with a Windows NT 4.0 image connecting to a domain on a Windows NT 4.0 Server. DHCP is running on the Windows 2003 server with a different subnet for each VLAN:

VLAN 1 =
VLAN 2 =
VLAN 3 =

DHCP has been set up with a range of 200 IP addresses in the pool for each VLAN with an 8-hour lease. With the VPCs running, VLAN 1 is running at about 70-percent capacity, VLAN 2 is running at around 50-percent capacity and VLAN 3 running at 20 percent.

The problem: Some PCs are unable to obtain an IP address from the DHCP server. We can fix this by recreating the VPC.vmc file or by editing it and removing the MAC address, but then another Virtual PC will have the same problem. We fix that and another will not connect; we fix that, then the first won't be able to get an IP address and so on.

The XP host PCs never have any problems connecting. We don't have any problems joining the NT VPCs to the domain when we first set them up.
— Andrei

Tech Help—Just An
E-Mail Away

Got a Windows, Exchange or virtualization question or need troubleshooting help? Or maybe you want a better explanation than provided in the manuals? Describe your dilemma in an e-mail to the editors at; the best questions get answered in this column and garner the questioner with a nifty baseball-style cap.

When you send your questions, please include your full first and last name, location, certifications (if any) with your message. (If you prefer to remain anonymous, specify this in your message, but submit the requested information for verification purposes.)

Andrei, your Virtual PC problem does have a small history. In fact, Microsoft recognized the potential for the problem. In the Virtual PC help file, you'll find this explanation from Microsoft:

If you create an image of a host operating system that includes Virtual PC and virtual machines configuration files (.vmc files) and copy that image to another computer, each virtual machine configuration file included in the image contains a MAC address. The MAC address will not be reset automatically when you place the image on a new physical computer. As a result, the virtual machines that are copied onto the new computer will have the same MAC addresses as the virtual machines on the computer that was used to create the image.

The help file will further go on to state that a solution is to delete the MAC address reference in the Virtual PC's associated .vmc file and a new MAC address will be automatically generated the next time the Virtual PC starts. In the .vmc file, you'll see a line that reads:

<ethernet_card_address type="bytes">0003FFxxxxxx</ethernet_card_address>

The MAC address referenced in the file will always exist between the two ethernet_card_address tags. To cause Virtual PC to generate a new MAC address the next time the VM starts, delete the MAC address referenced in the file so that the line reads:

<ethernet_card_address type="bytes"></ethernet_card_address>

In fact, this is a recommended best practice when copying a single Virtual PC image to several host systems.

As you already mentioned, you have attempted this procedure without any luck. This is due to the behavior of the Virtual PC algorithm that generates the MAC address. When a MAC address is created, Virtual PC will check to ensure that the MAC address does not exist on the local LAN segment before assigning it to the Virtual PC. However, when separated by three VLANs, this default behavior will not work. This can cause the MAC address conflicts and, thus, the intermittent problems with obtaining DHCP leases.

To solve this problem, you can take two approaches. Some of you are probably thinking "Yeah, get rid of Virtual PC and replace it with VMware Workstation!" But, that isn't one of the solutions I'm considering here. The first solution is to statically assign MAC addresses in the .vmc file of each Virtual PC VM. The Virtual PC MAC address prefix is 0003FF. So a workaround would be to statically assign new MAC addresses, such as: 0003FF000001, 0003FF000002, 0003FF000003, 0003FF000004, 0003FF000005, and so on. This approach would prevent MAC address conflicts altogether and allow each VM to reliably obtain its own DHCP lease.

Another approach is to use the Virtual PC "Shared Networking (NAT)" network binding, instead of directly binding each Virtual PC to the physical network adapter of the host. This is configured by opening Virtual PC, clicking on a Virtual Machine, and then clicking the Settings button. From the Settings window, you then click Networking and select Shared Network (NAT) from the drop-down menu on the right-side of the window. With NAT configured, the Virtual PC would automatically receive a DHCP address from the host system and would be assigned the same DNS server that the host is configured to use. With this approach, having the host systems obtain a DHCP address is all that's needed. The NATing provided by Virtual PC would give each VM access to network resources, including allowing them to join the domain.

With either of these approaches, you should be able to reliably connect each Virtual PC to your LAN.

About the Author

Chris Wolf is a Microsoft MVP for Windows --Virtual Machine and is a MCSE, MCT, and CCNA. He's a Senior Analyst for Burton Group who specializes in the areas of virtualization solutions, high availability, storage and enterprise management. Chris is the author of Virtualization: From the Desktop to the Enterprise (Apress), Troubleshooting Microsoft Technologies (Addison Wesley), and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).learningstore-20/">Troubleshooting Microsoft Technologies (Addison Wesley) and a contributor to the Windows Server 2003 Deployment Kit (Microsoft Press).

comments powered by Disqus
Most   Popular

SharePoint Watch

Sign up for our newsletter.

Terms and Privacy Policy consent

I agree to this site's Privacy Policy.