I’ve recently posted several entries on MAC address conflicts within vCenter:
Multiple vCenters and MAC address conflicts
Virtual Machines with Duplicate MAC addresses
If you look at the first post (and VMware KB 1024025) you’ll notice that vCenter uses a random instance ID to come up with the automatically generated MAC addresses. If you look at the second post, you’ll notice that it is possible for virtual machines to retain their automatic MAC assignment when moving between vCenters — and for the source vCenter to reissue that MAC. This can lead to problems with multiple MAC addresses on the same network.
What we need to know now is which virtual machines have automatic MAC addresses generated by another vCenter.
I looked at a couple of vCenter instance IDs and compared them to the automatically generated MAC addresses. Here is what I found:
vCenter with instance ID 50 will generate a MAC prefix of 00:50:56:b2
vCenter with instance ID 60 will generate a MAC prefix of 00:50:56:bc
The important things to note are that:
1.) only the fourth octet of the MAC changed
2.) the fourth octet changed by exactly 10 in hexadecimal
Converting B2 in hexadecimal returned 178 in decimal. BC in hexadecimal is 188 in decimal. Since the fourth octet of the MAC address grows linearly with the instance ID, I took 178 and subtracted the instance ID of 50, which returned 128. To prove this idea, I then changed the instance ID on a test vCenter to 0, rebooted and then added a network adapter to a VM. As expected, the fourth octet of the MAC address was 80 (or 128 in decimal).
The automatically generated MAC address has a fourth octet of 128 + the vCenter instance ID converted to hexadecimal.
With this understanding of how the MAC address is generated, I turned back to PowerCLI to help figure out which virtual machines had automatically assigned MAC addresses from other vCenters.
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
| # http://communities.vmware.com/thread/339358
# Modified to find MAC addresses generated from other vCenter servers
$myreport = $null
$global:DefaultVIServers | %{
Write-Host "Starting vCenter $($_.name)"
$si = Get -View ServiceInstance -Server $_.name
$set = Get -View $si.Content.Setting -Server $_.name
$vCenterInstanceID = ($set.Setting.GetEnumerator () | where {$_.key -eq "instance.id"}).value
$vCenterMac4 = [Convert ]::ToString ((128 + $vCenterInstanceID), 16)
$vCenterMacPrefix = "00:50:56:$vCenterMac4"
Write-Host "Expected MAC prefix of $vCenterMacPrefix"
$vCenterName = $_.Name
$myreport += Get -View -ViewType VirtualMachine -Server $_.name -Property Name , Config.Hardware.Device -Filter @{"Config.Template"="False"} | %{
$viewThisVM = $_
$viewThisVM.Config.Hardware.Device | ?{$_ -is [VMware.Vim.VirtualEthernetCard ]} | %{
New-Object -Type PSObject -Property @{
VMname = $viewThisVM.Name
NICtype = $_.GetType ().Name
MacAddress = $_.MacAddress
AddressType = $_.AddressType
vCenterName = $vCenterName
vCenterMacPrefix = $vCenterMacPrefix
} ## end new-object
} ## end foreach-object
}
}
$myreport | where {$_.MacAddress -notmatch "^$($_.vCenterMacPrefix)" -AND $_.AddressType -eq "assigned"}
#The caret in the notmatch comparison signifies the start of string in regex |
The returned list includes the virtual machines that have automatically assigned MAC addresses that do not match their current vCenter. I know exactly which virtual machines need new/modified MAC addresses to resolve my duplicate MAC issues — without them coming back in the future.
I have tested the following code to get vCenter to generate a new automatic MAC address for a virtual machine:
1
2
3
4
| $thisAdapter = Get-NetworkAdapter VMNAME
$thisAdapter.ExtensionData.AddressType = "Generated"
$thisAdapter.ExtensionData.MacAddress = ""
Set-NetworkAdapter $thisAdapter -confirm:$false |
Virtual Machines will need to be powered off/on for the guest operating system to be made aware of this change. Testing shows that Windows virtual machines retain static IP configuration after this change, but Linux guests detect a new network adapter and required re-setting IP information. Your mileage may vary, as always, test before making changes in your production environment.
