We’ve recently been piloting a laptop developer build on Windows Server 2008 R2 Release Candidate (Build 7100) with the Hyper-V role. One of the first receipients of this build complained of connectivity problems in Office Communicator once every minute or two. For as-yet undiagnosed reasons we have lengthy sign-in times for Communicator, so this loss of connectivity rendered it completely unusable. This same problem was visible in Outlook, although less disruptive since we use Cached Exchange Mode. Both Exchange and the OCS server are hosted but we also noticed the problem with interrupted file transfers so it clearly wasn’t just an internet connectivity issue. It looked like something to do with the NIC, the cable or a network device.
Port ‘SWITCHPORT-SM-F277C685-E5F8-490D-8CD1-913B854FABD2-0-1′ was prevented from using MAC address ’00-15-C5-7E-EB-39’ because it is pinned to port ‘SWITCHPORT-SM-F277C6’.
The only coverage I could find on similar topics suggested it might be a MAC conflict or a problem with the physical switch at the end of the wire.
The first thing I checked was the host’s external connection’s MAC address and whether it resided in the Hyper-V external network MAC pool (something I’d never inspected before). It turned out it wasn’t. Each laptop with this image had its own randomly-generated MAC pool, as the Hyper-V role was manually added post-deployment. In short, a MAC conflict on a Hyper-V MAC pool range seemed unlikely, especially since the host’s adapter wan’t even on that range.
Having exhausted the quick troubleshooting and investigative options, I set about fixing it, leaving the root cause for another day. These were the steps I took to resolve the issue in our environment, which assumes use of internet connection sharing (ICS) from a Hyper-V external network connection to a Hyper-V internal network connection:
- Disable the ICS connection in any running guest VMs
- Disable ICS in the host
- Delete the external network in Hyper-V Manager
- Uninstall the host’s physical NIC in Device Manager
- Scan for new devices
- Add a new External Network using the newly reinstalled device, called Hyper-V External Network in Virtual Network Manager
- Rename the Local Area Connection in the host to Virtual Network Switch
- Rename the new Local Area Connection for the host’s external network connection to Host External Network Connection
- Share ICS from the Host External Network Connection to the Host ICS Network Connection
- Re-enable the ICS adapter in the running guest VMs
- Confirm that the System event log errors are resolved and that the connection appears to be stable
This has only happened once in a number of deployments of this build, so I suspect it’s a fluke. If it arises again it will be worth tracking MAC address allocation throughout this process, as the host external connection will change from the old conflicting MAC to the physical MAC when the adapter is reinstalled to a new MAC when the NIC is given to Hyper-V again. One assumes that if a new MAC is not generated the problem will persist, based on that error message.
Update (15/09/09): this has now happened twice more but I haven’t been able to pin down a cause still. In each case the fix has been straight-forward, as above and the problem has not returned on those machines.
Update (22/10/09): Further updates.
After checking out a handful of the blog articles on your blog, I seriously appreciate
your way of writing a blog. I bookmarked it to my bookmark site
list and will be checking back soon. Please check out my website as
well and tell me your opinion.