System Center is great for managing your virtual environment, but what if you do not have the resources (human or capital) to use it? Hyper-V is either free or included with your Windows licensing, and with the benefit of a virtual environment would be foolish to go unused.
Being employed by Managed Service Providers (MSP) for my IT career has given me the need to manually solve a number of issues the enterprise world has automatically managed for them after implementing expensive software coupled with a large number of people-hours. One of those is MAC address management across same site and/or disparate-site deployments linked together by a Remote Monitoring and Management (RMM) platform such as Kaseya or LabTech.
The default behavior of Hyper-V includes assigning MAC addresses dynamically to Virtual NICs that are configured on the host. The algorithm used to determine that pool is limited in scope, which can create duplicate addresses across hosts in the same site (if you use more than a single host) as well as across client locations if your machines check into an RMM.
By default Hyper-V uses an Organizationally Unique Identifier (OUI) 00:15:5D from Microsoft, followed by a standard set of two hexadecimal pairs that are derived from the IP address of the host, followed by the final hex pair with values in the range 00-FF. See here for details. Since the only determination of the pool is by the IP address of the host, and you are deploying more than one host to that subnet, it is entirely likely you will have MAC Address conflicts on the network. Additionally, if you use an RMM that uses MAC address sign-up, you are much more likely to encounter this issue. Many clients would have over-lapping subnets (think about how many you’ve inherited that are using 192.168.1.x) that would then have their guests using over-lapping MAC addresses, which then all check into your RMM. Symptoms would be disappearing client machines, client machines moving “randomly” between client locations.
In order to rectify this problem, I started researching private MAC address ranges. I found that MAC addresses with the following format are “locally administered”-which basically means the same thing as private non-routable IP addressing (much like the above example 192.168.1.x):
x2:xx:xx:xx:xx:xx
x6:xx:xx:xx:xx:xx
xA:xx:xx:xx:xx:xx
xE:xx:xx:xx:xx:xx
You can replace the x’s with any hex character, 0-F. What I derived, however, was a way to document each of my client locations such that the first pair was used as an arbitrary starting point. For example, 22. The next three pairs I used for my client locations, which with my RMM meant that I’d be using only digits: 0-9. If my RMM location ID (not site ID) was 307, for example, I’d use 22:03:07:xx:xx:xx. The fifth pair I decided to use for a host ID at that specific location, which I’d match with my naming convention so it would easily identify which host that particular NIC (and therefore, virtual machine) resides on: 22:03:07:00:01:xx. Now we can have site location 307 with the ability to have 256 hosts per site. The last pair would then allow for 256 guest NICs per host.
We could of course tailor this to suit a lesser number of site locations and then increase the amount of hosts/guests. This particular setup worked well for me, and I won’t have to worry about changing it any time soon. As long as you document somewhere which host ID’s are in use, you shouldn’t ever run into a conflict with your guest MAC addresses.
