John Howard - Senior Program Manager in the Hyper-V team at Microsoft : Virtual Server

Hyper-V: MAC Address allocation and apparent network issues MAC collisions can cause

jhoward — Wed, 16 Jul 2008 06:02:00 GMT

In a physical only world, you don’t usually have to worry about MAC addresses that much as each NIC vendor carves off a MAC address from their ranges which have been allocated to them. However, in a virtual environment, you have to be a little more careful, particularly if you are using dynamic MAC address assignment. This post looks at how Hyper-V allocates dynamic MAC addresses and some potential problems you can face. So often it can be the last thing people think to check, but can be the root cause of otherwise unexplained network oddities.

Here’s a screenshot of a typical MAC collision problem – pings sometimes work, sometimes fail – and this is all on a local isolated network.

To start the walkthrough, I have a base install of Windows Server 2008 on a server with a single physical NIC – against best practice, but it serves fine for demonstration. I have already installed the RTM update (KB950050) to the server, but have not yet added the Hyper-V role. Let’s look at an output of “ipconfig /all”. You can see that the MAC address of the physical NIC is 00-13-20-F5-F8-7D and I’m obtaining an IP address from a DHCP server on the private test network I’m using.

Now let’s use Server Manager to enable the Hyper-V role. Note that Server Manager allows you to create an external virtual network switch during role enabling, but I am choosing not to do this. Let’s see what has happened in the registry after the Hyper-V role is enabled. Specifically, I’m looking at two keys which have been created under HKLM\Software\Microsoft\Windows\NT\CurrentVersion\Virtualization, as-yet unpopulated: MinimumMacAddress and MaximumMacAddress, plus another key in the worker node, CurrentMacAddress – again as-yet unpopulated. (The astute walking through this in front of a machine will notice that CurrentMacAddress also appears in the Virtualization node. That key is not used though.)

Next, I’m going to create my first virtual machine. As I haven’t created any virtual network switches yet, I’ll leave the network disconnected. I don’t need a hard disk. Also, I’m deliberately choosing not to start it. Let’s see what’s happened in the registry. MinimumMacAddress and MaximumMacAddress have been populated with 00-15-5d-c8-6a-00 and 00-15-5d-c8-6a-ff respectively – a range of 256 possible MAC addresses.

So where did this range come from? The first three bytes are the Microsoft IEEE Organizationally Unique Identifier, 00-15-5D which we use in Hyper-V. The next two bytes, C8-6A are derived from the lowest two octects of an IPv4 address on the server (the first IP address as NICs are enumerated). If you look at the second screenshot in this post, the IPv4 address on the only NIC on this server was 192.168.200.106. In Hex, this is “C0.A8.C8.6A”. The last two octets or bytes are C8 and 6A. The last byte of the address range is automatically generated with a minimum 00 and maximum FF.

You can probably now realize, that while this algorithm will work for many people, it may not necessarily be perfect and cause MAC address range clashes. To cope with multiple Hyper-V enabled servers, you would need to ensure address ranges are managed at a higher level across those servers, such as the use of SCVMM.

Let’s go back to the virtual machine I created. By default, when a virtual machine is created, it is allocated a dynamic MAC address. This can of course be changed in the settings for the virtual machine. Here’s the setting for the blank virtual machine. Notice that it’s set to Dynamic and the MAC address in the “Static” boxes show 00-00-00-00-00-00

Now I’m going to start the Virtual Machine and open the settings. Although some settings cannot be changed while a virtual machine is running (including changing static/dynamic MAC, or the static MAC itself), notice that the boxes under the static MAC address radio button are now populated with the first MAC address in the range defined in the registry: 00-15-5D-C8-6A-00.

Now for a bit of fun (and to make the walkthrough a bit simpler), let’s change the registry so that the maximum MAC address is 00-15-5D-C8-6A-02. (I’ll also do a reboot just to make sure the change takes effect) This change means that we are limited to three possible dynamically assigned MAC addresses, the last octet being 00 (in use by the “Blank” VM), 01 or 02.

Now, I’m going to create another virtual machine named 6A-01 and power it on, then create a third virtual machine named 6A-02 and power that on too. Let’s look at the settings for each of these while all three virtual machines are running. As expected 6A-01 has a MAC address ending 6A-01 and 6A-02 has a MAC address ending 6A-02. That’s why we have the “CurrentMacAddress” registry key to track what MAC address to assign to VMs in turn.

Can you guess though at this point what would happen though if I create another virtual machine and power it on? I don’t have any MAC addresses left in my available range and all MAC addresses are currently in use.

Did you guess correctly? Let’s now power off the very first virtual machine (“Blank”) I created with MAC address 6A-00, and then try to run through the New Virtual Machine Wizard again with my “No MAC Addresses Available In Range” virtual machine. Try to guess what will happen at the end.

The virtual machine starts successfully and now has a duplicate MAC address to the first virtual machine I created, ‘Blank’:

Last quiz question: What would happen then if I tried to start “Blank” – will it start or not? After all, it has already been allocated a MAC address ending 6A-00.

Actually, we will detect this as you can see above and stop the virtual machine from powering on. So in some ways, on a single Hyper-V enabled server, we’re relatively immune to duplicate MAC addresses across virtual machines running on a single server. However, due to the algorithm for choosing the ranges of MAC addresses, while relatively safe, there is no guarantee of being unique across an entire network. And of course, chances are that you will want packets from or to virtual machines on a Hyper-V server to “hit” the physical network.

So hopefully that gives you a better idea why it is important to manage MAC addresses across multiple servers in a virtual machine environment. While the walkthrough above was specific to Hyper-V, the same types of issues could arise in Virtual Server.

Cheers,
John.

Blogcast on VSMT (Virtual Server Migration Toolkit) - Part 5

jhoward — Sun, 09 Jan 2005 03:02:00 GMT

As promised, here's the last blogcast installment walking through a VSMT migration of an NT4 server into a virtual machine running under Microsoft Virtual Server 2005. This blogcast walks through deploying the disk image into the blank VM and seeing the final result. It can be viewed by clicking here (10 minutes 6 seconds).

If you missed any of the previous parts:

Part one can be viewed here
Part two can be viewed here
Part three can be viewed here
Part four can be viewed here

Edited by John: 3rd Nov 2005 - Rehosted WMV File

Blogcast on Virtual Server Migration Toolkit (VSMT) - Part 4

jhoward — Fri, 07 Jan 2005 06:54:00 GMT

I'm "virtually" (no pun intended) at the end in the series of blog entries walking you through a VSMT migration of an NT4 server into a virtual machine running under Microsoft Virtual Server 2005. If you've missed out so far:

Part one can be viewed here (links to 2 blogcasts)
Part two can be viewed here (links to 2 blogcasts)
Part three can be viewed here (links to 2 blogcasts)

The seventh and penultimate VSMT blogcast walks through creating a new virtual machine under Virtual Server as a placeholder for the migrated server. It can be viewed by clicking here (6 minutes 55 seconds).

I've had some great feedback about this series from a truly worldwide audience - the level of interest has been absolutely staggering, and I thank you for taking the time to provide feedback. If you would like more of this type of demonstration/blogcast, please drop me an email using the contact me option on the home page of my blog. I'll try my best to accomodate, but I need to know what you want to see....

Edited by John: 3rd Nov 2005 - Rehosted WMV file

Blogcast on Virtual Server Migration Toolkit (VSMT) - Part 3

jhoward — Thu, 06 Jan 2005 11:41:00 GMT

If you missed my two previous postings in this series of blogcasts walking you through a VSMT migration of an NT4 server into a virtual machine running under Microsoft Virtual Server 2005, part one can be viewed here, and part two can be viewed here.

This blog provides links to the next two blogcasts parts five and six:

The fifth VSMT blogcast walks through updating the script files to ensure the generated P2V migration files work correctly in the environment validating the XML file describing the hardware on the server being migrated and adds an device to ADS for the target Virtual Server machine. It can be viewed by clicking here (2 minutes 46 seconds).

The sixth VSMT blogcast walks through capturing a disk image of the NT4 server into ADS. It can be viewed by clicking here (7 minutes 33 seconds).

Edited by John: 3rd Nov 2005 - Rehosted WMV files

Blogcast on Virtual Server Migration Toolkit (VSMT) - Part 2

jhoward — Wed, 05 Jan 2005 19:01:00 GMT

I hope you enjoyed the first two blogcast demonstrations of VSMT I blogged about yesterday. Today, I'm publishing part two which contains the next two blogcasts in the series.

The third VSMT blogcast walks through validating the XML file describing the hardware which the server being migrated is running. It can be viewed by clicking here (1 minute 23 seconds).
The fourth VSMT blogcast walks through generating the P2V (physical to virtual) files used for the remainder of the migration. It can be viewed by clicking here (2 minutes 44 seconds).

Edited by John: 3rd Nov 2005 - Rehosted WMV Files

Blogcast on Virtual Server Migration Toolkit (VSMT) - Part 1

jhoward — Tue, 04 Jan 2005 20:17:00 GMT

Blogcast, podcast, mini-webcast.... What's in a name - well quite a lot judging by some of the reactions I've had.

Leaving the name issue to one side, I've recorded a series of eight clips which walk through the process of migrating an NT4 server into Microsoft Virtual Server 2005 using the VSMT (Virtual Server Migration Toolkit). Each of these clips is only a few minutes long, with the longest one only 10 minutes. Please feel free to delve in as you want. These clips essentially run through the steps described in a fabulous white paper available on microsoft.com

You will be able to see demo live in Birmingham on January 13th where you can ask me questions in-person.

The first blogcast is an introduction to the environment I'm using to perform the migration and can be viewed by clicking here.

The second blogcast is using the gatherhw tool to generate an XML manifest cataloguing the hardware in my NT4 Server. This can be viewed by clicking here

Hope you enjoy these - I'll blog about the other recordings over the next few days. Also, if you want to see more of these type of recordings relating to Windows Server environments or Virtual Server, drop me a mail or add a comment.

--------------------------------

...added 28th January 2005: Now that they're published, here's the links to the other parts to save you searching.
Part two can be viewed here
Part three can be viewed here
Part four can be viewed here
Part five can be viewed here

Edited by John: 3rd Nov 2005 - Rehosted WMV files