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.
I was having similar issues. It turns out I had a duplicate MAC address.
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.
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.
Hi Mike,
Yeah, I believe that is the case with P2V, but so you know this is an issue with Hyper-V hosts, not the virtualised guest.
Cheers,
Tristan
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.
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.
Thank you very much for the information and your help. I appreciate the fact that you make this all publicly available.
No problem! Hope it was helpful.