Further to my post from a few months ago on the this topic (dating back to the RC build), I’ve seen this same problem a few more times on the RTM build of Windows Server 2008 R2. My suggested approach still fixes the problem and it doesn’t recur, but I’ve still not been able to pin down a cause and I can find no documentation on host machine MAC assignments anywhere. Search engines results are entirely focused on MAC pool duplication, which should be a completely distinct issue since the MAC address in question falls outside of Hyper-V’s MAC pool.

To help pin this down, I will add that this Hyper-V host machine has been deployed from a WDS image, but I initially discounted that as an issue because the Hyper-V role is not part of the image; it is added during the deployment as specified in an unattended installation file and the Hyper-v networks are created by script post-deployment. Since the Hyper-V host’s MAC address is distinct from the physical adapter’s address, I’ve been assuming that there must be an algorithm that generates the host’s virtual MAC address uniquely, but given that this problem seems to manifest itself soon after installation I’m leaving this possibility on the table.

I’ve noticed a fair amount of traffic for this topic. If you’re having the same problem and this suggestion fixes it, I’d be grateful to know if the Hyper-V system was deployed from an image, as that might help to narrow the troubleshooting effort.

12 Responses to More on routine loss of external network connectivity on Hyper-V hosts (not guests)

  1. [...] (22/10/09): Further updates. Tagged as: connectivity, Hyper-V, ICS, MAC, MVSMP, Windows Server 2008 R2 Leave a comment [...]

  2. [...] previously reported problems with MAC duplication on Hyper-V host external network connections on Windows Server 2008 R2, which I've never fully resolved, although we have been successfully [...]

  3. Zach says:

    I was having similar issues. It turns out I had a duplicate MAC address.

  4. iRReeL says:

    Currently being flooded by this event ID 28. The virtual PC’s I am using are all installed from scratch, so no imaging etc. Still investigating for possible solutions / workarounds. Thanks for publishing your efforts and suggestions.

  5. I was using the same NIC to complete the P2V process (due to driver compatibility) and didn’t realize the mac was being copied form this source.

  6. trmcbr says:

    Any further information on this? I’m having this problem as I type this. Exact problem you speak of with the host not being able to ping the default gateway and I receive the message in Event Viewer > System, “Port ‘SWITCHPORT-SM-09690C11-AD50-4BBD-953D-B2428D62AB36-0-1′ was prevented from using MAC address ’00-21-9B-6E-8D-79′ because it is pinned to port ‘SWITCHPORT-SM-09690C’.”

    I don’t even recognize the MAC address 00-21-9B-6E-8D-79. The host MAC address is 00-23-AE-91-90-D7, not even the same OUI. The Dynamic MAC address pool for Hyper-V is 00-15-5D-1C-32-00 to 00-15-5D-1C-32-FF.

    I’m having this problem on Windows Server 2008 R2 with Hyper-V as the only enabled role. I’m in a classroom with 21 computers which were all disk imaged via Ghostcast so the VM’s MAC addresses are identical but I don’t understand, when the VM’s are turned off, how this could cause a problem with the Host machine’s network.

    I do believe though that it has something to do with duplication because with just one computer turned on, the internet speed is fine and the only symptom is that it won’t ping the default gateway. However as more machines are turned on the network performance gets worse.

    I had a Network Technician over here earlier to confirm everythign was configured properly and functional on the switch. I have this classroom set up for Microsoft 6420B Fundamentals of Windows Server 2008 and my previous semesters’ configurations have not had this problem. The only difference between previous set-ups and this set-up is that I had an XP partition on the disk in previous set-ups, now it’s just two partitions of 7 x64, one of Vista x64, and the partition of Server 2008 R2 in question here. The previous arrangement with XP did require a post-imaging start-up repair and Hyper-V removal and re-installation and the NIC’s on the VM’s to all be set again to ‘Private Network’. But I’ve tried all that again and still no change.

    Any help would be greatly appreciated.

    • Hiya. I’m afraid I don’t have any further insight, although it sounds like the same problem, and we’re still experiencing it. I wouldn’t worry about the VMs or the dynamic MAC address pool. This is an issue with the Host’s NIC on the external network, which doesn’t get allocated from that pool. My work-around still works as a means of resolving the problem though.

  7. trmcbr says:

    Here is a variation of your work-around that I’m applying and it seems to be working. Some steps may be unnecessary but it seems to be acheiving the desired result:

    1. Remove the virtual networks in Hyper-V
    2. Uninstall the Host network adapters
    3. Remove the Hyper-V role (auto-restart x2)
    4. Install Hyper-V role (auto restart x2)
    5. Verify Host network adapters re-installed during restart
    6. Disable unnecessary PCI NIC (I have two NIC’s, only need one for this environment)
    7. Create needed virtual networks
    8. Set network adapter in each VM to appropriate network

    Interesting note, I used to set up this class on a disk that had an XP partition on it as well. Due to XP’s different boot files vs. those now used for Vista, 7, and Server 2008, back then I was forced to perform ‘post-imaging’ a start-up repair on the partitions which used bcd (Vista, 7, 2008). I also had to remove and re-install the Hyper-V role so it’s virtual BIOS was set-up correctly. These were both disrupted due to the imaging process with Symantec Ghost. I think that repair was also resolving the issue we are discussing here without me knowing it because I was forced to do it for these other reasons. So I would say yes, this is all related to the imaging process.

    • Agreed, but without knowing more about how you’re using Ghost (or indeed, how Ghost works with later-generation operating systems), it would be hard to add any insight. In my case, we are using Windows Deployment Services but we add the Hyper-V role after the machine has been SysPrep’d and deployed to the new instance. There seems to be something in the SysPrep process which doesn’t get reset, related to the Hyper-V host’s external NIC MAC allocation. Obviously, figuring this out would require quite a bit of insight in to these internal processes and I have zero appetite to plunder it further, because the work-around works and we’re moving away from Hyper-V to VMware on Windows 7, for many reasons I’ve discussed elsewhere here.

      For what it’s worth, if you’re removing Hyper-V and adding it back in, that is probably curing whatever causes the MAC duplication in your environment, although I would anticipate that removing and adding the external network (which claims a host NIC) would be sufficient. That’s pretty much the differences between our approaches.

Leave a Reply

Your email address will not be published.

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

Set your Twitter account name in your settings to use the TwitterBar Section.