Find VM by NIC MAC Address with PowerShell -- Fast Like!

There is the occasion on which it would be handy to find a VM based on a known MAC address. Say, for example, there is a duplicate IP address on the network, and the network team informs you of the offending MAC addresses. Unfortunately, there is not a simple/easy way to go about this.

There are some places on the web that discuss this topic, but none were satisfactory. Some were overly complex, storing objects and data without need. Others were written with the ease of writing being considered. While these will work, they do not suffice if the size of the environment is larger. Memory usage climbs in the PowerShell session, and the time-to-run grows far past what is necessary and desirable.

Yet another problem was the reliance of some scripts on VMware Tools to get the information. Granted, VMs would ideally have Tools current and running, but, we all know that in the real world, that just does not always happen.

So, we wrote a little nugglet that will get the VM(s) that have VirtualEthernetCard(s) with the given MAC address:

## Script function: find all VMs with one or more NIC with the given MAC address
## Author: vNugglets.com -- Aug 2011

## MAC addr of NIC(s) to find
$strMacToFind = "00:50:56:83:00:69"
## return the .NET View object(s) for the VM(s) with the NIC w/ the given MAC
Get-View -Viewtype VirtualMachine -Property Name, Config.Hardware.Device | ?{$_.Config.Hardware.Device | ?{($_ -is [VMware.Vim.VirtualEthernetCard]) -and ($_.MacAddress -eq $strMacToFind)}}

This is pretty straight forward to use: just set the variable for the MAC address to find, and then run the next line of code. This returns the .NET View object(s) for the VM(s) that have a NIC with the given MAC address. One could then do as they pleased with the objects.

To just report the info about the VM(s) with a NIC with the given MAC address, one could add a simple Select-Object statement. The following returns a list of matching VMs' names and their associated NICs' MAC addresses:

Get-View -Viewtype VirtualMachine -Property Name, Config.Hardware.Device | ?{$_.Config.Hardware.Device | `
?{($_ -is [VMware.Vim.VirtualEthernetCard]) -and ($_.MacAddress -eq $strMacToFind)}} | `
Select name, @{n="MAC(s)"; e={($_.Config.Hardware.Device | ?{($_ -is [VMware.Vim.VirtualEthernetCard])} | %{$_.MacAddress}) -join ","}}

The output would be something like:

Name     MAC(s)
----     ------
myVM     00:50:56:83:00:69,00:0c:29:00:08:01

PS C:\>

As for speed: this method of finding VMs with a given MAC address took around 25 seconds when run in a test environment of about 3200 VMs. Fast. Enjoy.

Update (30 Oct 2011 -- response to comment):
To use a similar technique to find a VMHost with a given MAC address, you can look at the Config.Network.Pnic property of a HostSystem .NET View object.  To find a VMHost with a given MAC, and quick like, use:

## to find a VMHost with given MAC address:
$strMacOfNICOnVMHostToFind = "00:0e:0c:00:00:01"

Get-View -ViewType HostSystem -Property Name, Config.Network.Pnic | ?{$_.Config.Network.Pnic | ?{$_.Mac -eq $strMacOfNICOnVMHostToFind}} | select Name, @{n="MAC(s)"; e={($_.Config.Network.Pnic | %{$_.Mac}) -join ","}}

The output is similar to the output above, but the Name will be of the given VMHost, and MAC(s) will be that host's MAC addresses. Enjoy, "Anonymous" commenter.

Find Duplicate VM NIC MAC Addresses Using PowerShell

We were having issues with some VMs and their networking. Unexpected, unexplained things were happening, and eventually someone thought that there might be some duplicate MAC addresses in the mix, causing grief. Some of the VMs had been copied from other vCenters, among other things.

Side note by AC: the unique ID of a vCenter server helps dictate the range of assigned MAC addresses for VMs in that vCenter. Therefore, in order to avoid MAC address duplicates, one should ensure that no vCenters within the same network have the same unique ID.

So, to find if there were any duplicate MAC addresses in use by VM NICs, we whipped up the following:

## Script function: find duplicate MAC addresses, and list the VMs/addresses involved
## Author: vNugglets.com

## get VirtualMachine .NET views where the items is not marked as a Template
$colDevMacAddrInfo = `
Get-View -ViewType VirtualMachine -Property Name,Config.Hardware.Device -Filter @{"Config.Template" = "False"} | %{
   $strVMName = $_.Name
   $_.Config.Hardware.Device | Where-Object {$_ -is [VMware.Vim.VirtualEthernetCard]} | %{
       New-Object -Type PSObject -Property @{VMName = $strVMName; MacAddr = $_.MacAddress}
   } ## end foreach-object
} ## end foreach-object

## are all of the MAC addresses unique?
($colDevMacAddrInfo | Select-Object -unique MacAddr).Count -eq $colDevMacAddrInfo.Count

## get the non-unique MAC addresses, returning objects with the count of the duplicates, the duplicate MAC, and the VM names that have the duplicate MAC
$colDevMacAddrInfo | Group-Object MacAddr | Where-Object {$_.count -gt 1} | Select-Object Count,@{n="DuplicateMAC"; e={$_.Name}},@{n="VMNames"; e={($_.Group | %{$_.VMName}) -join ","}}

It uses the Get-View cmdlet with the -Property parameter to ensure minimum memory usage and maximum speed.

Line 14: quick check to determine if there are any duplicate MAC addresses present -- compares the count of unique addresses to the total count of addresses

If there are duplicate MAC addresses, line 17 returns some nice information about the given MAC address, the count of VM NICs that have it, and the names of the VMs involved.

Once one finds the offending VMs, they can use something like the script in the vNugglets post Setting MAC Address for VM NICs using PowerShell to change the necessary MAC addresses and return things to standard working order. Hurray!

Backup/Export Full DRS Rule Info via PowerShell

Updated 22 Jan 2015
Luc Dekens and I got together on a new PowerShell module for managing/exporting/importing DRS Rules and Groups. See our posts at http://www.lucd.info/2015/01/22/drsrule-drs-rules-and-groups-module and http://www.vnugglets.com/2015/01/drsrule-new-powershell-module-for-drs.html for all of the juicy details. Going forward, that DRSRule module is the way to go. I am leaving this post intact for posterity. Enjoy!
End of update - 22 Jan 2015

We, like many, had the need for a way to backup our DRS rules. Searches turned up many pages, all of which had the same basic recipe: use the Get-DrsRule to grab the rules, get a few properties, and export to CSV.

The problem: Addressing the task getting all of the pertinent info for rules of type ClusterVmHostRuleInfo, or, "VM-to-Host" rules. Rules of this type do not have the VM IDs in a property of the rule, but rather have the VMGroupName and HostGroupNames properties. From these properties, and the .NET view object of the given cluster, one can retrieve the VMs' and hosts' info.

So, we did a little work, and wrote the following to, for all DRS rule types, get the information that would be required if one wanted to recreate the rules:

## Script function: Gather/export DRS rule info, including VMGroup and HostGroup members
## Author: vNugglets.com

## file to which to write the DRS rules' info
$strOutputFilespec = "e:\someFolder\DRSrules_export.csv"

## get cluster .NET view objects, which hold the info about the DRS rules
Get-View -ViewType ClusterComputeResource -Property Name, ConfigurationEx | %{
    ## if the cluster has any DRS rules
    if ($_.ConfigurationEx.Rule -ne $null) {
        $viewCurrClus = $_
        $viewCurrClus.ConfigurationEx.Rule | %{
            $oRuleInfo = New-Object -Type PSObject -Property @{
                ClusterName = $viewCurrClus.Name
                RuleName = $_.Name
                RuleType = $_.GetType().Name
                bRuleEnabled = $_.Enabled
                bMandatory = $_.Mandatory
            } ## end new-object

            ## add members to the output object, to be populated in a bit
            "bKeepTogether,VMNames,VMGroupName,VMGroupMembers,AffineHostGrpName,AffineHostGrpMembers,AntiAffineHostGrpName,AntiAffineHostGrpMembers".Split(",") | %{Add-Member -InputObject $oRuleInfo -MemberType NoteProperty -Name $_ -Value $null}

            ## switch statement based on the object type of the .NET view object
            switch ($_){
                ## if it is a ClusterVmHostRuleInfo rule, get the VM info from the cluster View object
                #   a ClusterVmHostRuleInfo item "identifies virtual machines and host groups that determine virtual machine placement"
                {$_ -is [VMware.Vim.ClusterVmHostRuleInfo]} {
                    $oRuleInfo.VMGroupName = $_.VmGroupName
                    ## get the VM group members' names
                    $oRuleInfo.VMGroupMembers = (Get-View -Property Name -Id ($viewCurrClus.ConfigurationEx.Group | ?{($_ -is [VMware.Vim.ClusterVmGroup]) -and ($_.Name -eq $oRuleInfo.VMGroupName)}).Vm | %{$_.Name}) -join ","
                    $oRuleInfo.AffineHostGrpName = $_.AffineHostGroupName
                    ## get affine hosts' names
                    $oRuleInfo.AffineHostGrpMembers = if ($_.AffineHostGroupName -ne $null) {(Get-View -Property Name -Id ($viewCurrClus.ConfigurationEx.Group | ?{($_ -is [VMware.Vim.ClusterHostGroup]) -and ($_.Name -eq $oRuleInfo.AffineHostGrpName)}).Host | %{$_.Name}) -join ","}
                    $oRuleInfo.AntiAffineHostGrpName = $_.AntiAffineHostGroupName
                    ## get anti-affine hosts' names
                    $oRuleInfo.AntiAffineHostGrpMembers = if ($_.AntiAffineHostGroupName -ne $null) {(Get-View -Property Name -Id ($viewCurrClus.ConfigurationEx.Group | ?{($_ -is [VMware.Vim.ClusterHostGroup]) -and ($_.Name -eq $oRuleInfo.AntiAffineHostGrpName)}).Host | %{$_.Name}) -join ","}
                    break;
                } ## end block
                ## if ClusterAffinityRuleSpec (or AntiAffinity), get the VM names (using Get-View)
                {($_ -is [VMware.Vim.ClusterAffinityRuleSpec]) -or ($_ -is [VMware.Vim.ClusterAntiAffinityRuleSpec])} {
                    $oRuleInfo.VMNames = if ($_.Vm.Count -gt 0) {(Get-View -Property Name -Id $_.Vm | %{$_.Name}) -join ","}
                } ## end block
                {$_ -is [VMware.Vim.ClusterAffinityRuleSpec]} {
                    $oRuleInfo.bKeepTogether = $true
                } ## end block
                {$_ -is [VMware.Vim.ClusterAntiAffinityRuleSpec]} {
                    $oRuleInfo.bKeepTogether = $false
                } ## end block
                default {"none of the above"}
            } ## end switch

            $oRuleInfo
        } ## end foreach-object
    } ## end if
} | Export-Csv -NoTypeInformation $strOutputFilespec

This bit of code, using the Get-View cmdlet for max speed and min memory footprint, starts off by getting a couple of select properties for all clusters. If the cluster has any DRS rules defined, then the code, for each rule:

• creates a new PSObject to hold the pertinent info about the rule
• includes basic rule info, the rule type, and info about the objects involved with the rule, including the VM group names/members and the host group names/members (for both Affine- and AntiAffine host groups)
• returns the object
• exports all of the gathered info to CSV for later consumption

Arnim van Lieshout wrote a good post with more information about DRS rules themselves at Managing VMware DRS rules using PowerCLI, and included a few functions for creating VMGroups ("Virtual Machines DRS Groups" in the vSphere client) and HostGroups ("Host DRS Groups"), and for creating new VM-to-Host rules. We will likely be using said functions for our "recreate the DRS rules/groups" work.

Setting MAC Address for VM NICs using PowerShell

A bit ago, there were some questions in the VMware VMTN community forums about setting explicit MAC addresses for VMs' NICs.

While this can be done via PowerCLI using the Set-NetworkAdapter cmdlet, the MAC address range is restricted to 00:50:56:00:00:00 - 00:50:56:3F:FF:FF when using the cmdlet, which is only a subset of the range that VMware uses.

An example came up where one might need to set the MAC address to something in a valid VMware range (with VMware OUIs like "00:50:56" or "00:0C:29") outside of the subset above. This can be done using the Web Services API, as it does not have the same range limitation as the cmdlet. The well-commented code below shows how to do so using the API:

## script function:  set the MAC address of a VM's NIC
## Author: vNugglets.com

## the name of the VM whose NIC's MAC address to change
$strTargetVMName = "myVM01"
## the MAC address to use
$strNewMACAddr = "00:50:56:90:00:01"

## get the .NET view object of the VM
$viewTargetVM = Get-View -ViewType VirtualMachine -Property Name,Config.Hardware.Device -Filter @{"Name" = "^${strTargetVMName}$"}
## get the NIC device (further operations assume that this VM has only one NIC)
$deviceNIC = $viewTargetVM.Config.Hardware.Device | Where-Object {$_ -is [VMware.Vim.VirtualEthernetCard]}
## set the MAC address to the specified value
$deviceNIC.MacAddress = $strNewMACAddr
## set the MAC address type to manual
$deviceNIC.addressType = "Manual"

## create the new VMConfigSpec
$specNewVMConfig = New-Object VMware.Vim.VirtualMachineConfigSpec -Property @{
   ## setup the deviceChange object
   deviceChange = New-Object VMware.Vim.VirtualDeviceConfigSpec -Property @{
       ## the kind of operation, from the given enumeration
       operation = "edit"
       ## the device to change, with the desired settings
       device = $deviceNIC
   } ## end New-Object
} ## end New-Object

## reconfigure the "clone" VM
$viewTargetVM.ReconfigVM($specNewVMConfig)

The ReconfigVM() method does not care if the new MAC address is a valid VMware MAC address. It does not even seem to care if the new MAC address string is a valid hex MAC address. So, use with care -- one would not want to break networking on their precious VM by setting its NIC to have an invalid MAC address, or a duplicate, etc.

Other info: the valid VMware OUIs can be found many places, like at the IEEE.org Public Listing search site.


Update 25 Nov 2011:
Do note that changing the MAC address of a VM NIC to something outside of the "accepted" range will cause other PowerCLI cmdlets and the vSphere client to report that the NIC's MAC is "not in the valid range", and may prevent further operations on that VM's NIC with those tools.  Thank-you to the anonymous commenter here and to LucD (in the VMware Communities thread at http://communities.vmware.com/message/1869800#1869800) for highlighting this point.


Update 31 Dec 2011:
The -Filter parameter for the Get-View call on line 10 was using a regular expression that had the possibility of returning more than one VM View object.  I have updated the regular expression to only match VMs of exactly the given name.  Thanks go to Joep Piscaer for pointing out the issue.  The code in this post has been updated.

Enable SIOC On All Datastores

After reading what Duncan at Yellow-Bricks.com had to say about enabling SIOC (Storage I/O Control) on all datastores here and here, we were inspired to write a script to avoid having to do it by hand on the 370 datastores in our environment. Of course, LucD already has a SIOC script but it was written before VMware fixed the StorageResourceManager bug in PowerCLI 4.1.1 that he had to use a workaround for. LucD's script allows you to both query and set values--we just wanted one that enabled SIOC on all datastores that supported it as quickly as possible. In addition, we wanted to schedule it (this script is not schedule-ready) to run on a regular basis so that it can enable SIOC on newly created datastores without admins having to worry about it.

This is what we ended up with:

## Script function: Enable SIOC (Storage I/O Control) on all datastores that support it and do not already have it enabled.
## Author: vNugglets.com


## Set up specification to enable SIOC
$spec = New-Object VMware.Vim.StorageIORMConfigSpec
$spec.Enabled = $True

## Create an array of datastore view objects that are SIOC capable and that do not already have it enabled
$arrSIOCableDatastores = @(Get-View -ViewType Datastore -Property Capability.StorageIORMSupported,IormConfiguration,Name -Filter @{"Capability.StorageIORMSupported" = "True"; "IormConfiguration.Enabled" = "[^(True)]"})

## Loop through each SIOC-ready datastore view (if any), then on the first run grab the "view" of the StorageResourceManager (this is needed to use the ConfigureDatastoreIORM_Task method to enable/disable SIOC) and finally, enable SIOC on the datastore
$arrSIOCableDatastores | ForEach-Object -Begin {$viewStorageRM = Get-View -Id "StorageResourceManager-StorageResourceManager"} {
    $viewStorageRM.ConfigureDatastoreIORM_Task($_.MoRef, $spec)
}

Of course, if you want to disable SIOC on all of your datastores you need to only modify two pieces of code:

Line 7: Simply change $True to $False.

Line 10: Remove the caret (^) on the second part of the filter so it finds datastores that already have SIOC enabled.

Depending on what you are looking for, you may choose LucD's script over this one, or maybe you'll use both since his contains two functions and gives you more granular control on which datastores to enable/disable SIOC.

Re-Registering VMs Removed from Inventory

The cache module on the array controller failed on a host, and ESXi was wasted. The host stopped responding in vCenter, but did not fail hard enough to trigger HA. Most of the VMs on it were still up and their OSes were responsive to ping requests. Eventually we had to remove the host from vCenter. At that point, all VMs registered on it also are removed from inventory.

I grabbed the info for the guests that were in "disconnected" state _BEFORE_ removing the affected host from vCenter, then removed the host, then re-registered VMs and started them as such:

## Script function:  re-register VMs after host removal from vCenter
## Author: vNugglets.com
## Jan 2011

## cluster in which troubled host resides
$strAffectedCluster = "myCluster"

## get array BEFORE removing bad host from vCenter!!!  Else, will not be able to get this info in this manner, since disconnected VMs are removed from inventory at that time, too

## get an array of VM .Net View objects where their OverallStatus is "gray"; optimized for low memory consumption
$arrVMsToHandle = Get-View -ViewType VirtualMachine -SearchRoot (Get-Cluster $strAffectedCluster | Get-View).MoRef -Property Name,Parent,LayoutEx.File,Summary.OverallStatus -Filter @{"Summary.OverallStatus" = "gray"}

## get the hosts in the cluster, to be used for re-registering VMs
$arrHostsInAffectedCluster = Get-Cluster $strAffectedCluster | Get-VMHost

## for each set of VM name, parent folder ID, and .VMX file path, add VM to inventory via New-VM cmdlet; add to random host within the cluster
$arrVMsToHandle | Select Name, Parent, @{n="vmxFilePath"; e={($_.layoutex.File | ? {$_.name -like "*.vmx"}).name}} | %{
    New-VM -VMFilePath $_.vmxFilePath -VMHost ($arrHostsInAffectedCluster | Get-Random) -Location (Get-VIObjectByVIView $_.Parent) -RunAsync
} ## end ForEach-Object

## start all of the VMs (may cause a boot storm if huge number of VMs -- split up by groups of x VMs as necessary)
$arrVMsToHandle | %{Start-VM $_.Name -RunAsync}

You could also have put the "Start-VM" call inside of the "ForEach-Object" loop (say, before line 19), but that makes the process more linear than quick. This would require the removal of the "-RunAsync" from the "New-VM" call on line 18.

This could come in handy for you someday. Enjoy!

Working with multiple default servers

Connect-VIServer has a new behavior/feature as of the 4.0 Update 1 release: "Working with multiple default servers." So what? So this: connecting to hosts that are not managed via a vCenter instance and taking actions against inventory items.

"vSphere PowerCLI supports working with multiple default servers. If you select this option, every time when you connect to a different server using Connect-VIServer, the new server connection is stored in an array variable together with the previously connected servers, unless the -NotDefault parameter is set. This variable is named $DefaultVIServers and its initial value is an empty array. When you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against all servers stored in the array variable. To remove a server from the $DefaultVIServers variable, you can either use Disconnect-Server to close all active connections to the server, or modify the value of $DefaultVIServers manually."
(from http://www.vmware.com/support/developer/windowstoolkit/wintk40u1/html/Connect-VIServer.html)

An example of the new behavior in action:

PS C:\> Connect-VIServer vcenter4.local
WARNING: There were one or more problems with the server certificate:
* The X509 chain could not be built up to the root certificate.

Login Information
Please supply user credentials.
User: vNuggsAdmin
Password for user vNuggsAdmin:  ***********

Name                                    Port                       User
----                                    ----                       ----
vcenter4.local                          443                        vNuggsAdmin


PS C:\> Connect-VIServer standAloneHost0.local
WARNING: There were one or more problems with the server certificate:
* The X509 chain could not be built up to the root certificate.
* The certificate's CN name does not match the passed value.

Login Information
Please supply user credentials.
User: root
Password for user root:  ***********

Working with multiple default servers?

  Select [Y] if you want to work with more than one default servers. In this case, every time when you connect to a different server using Connect-VIServer, the new server connection is stored in an array variable together with the previously connected servers. When you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against all servers stored in the array variable.
  Select [N] if you want to work with a single default server. In this case, when you run a cmdlet and the target servers cannot be determined from the specified parameters, the cmdlet runs against the last connected server.
  You can change your preference at any time using the DefaultServerMode parameter of Set-PowerCLIConfiguration.
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"): Y

Name                                    Port                       User
----                                    ----                       ----
standAloneHost0.local                   443                        root


PS C:\> $DefaultVIServers
Name                                    Port                       User
----                                    ----                       ----
standAloneHost0.local                   443                        root
vcenter4.local                          443                        vNuggsAdmin


PS C:\>

At this point, running a cmdlet that is not VIServer specific (as determined by the specified parameters) runs against all the servers to which this session is connected, namely "standAloneHost0.local" and "vcenter4.local." So, you can now act on all items in these servers' inventory.

A few notes:

• If connecting to a vCenter instance and a host which is managed by that vCenter instance, cmdlets will return the items in the host's inventory twice: once when the cmdlet runs against the vCenter server, and once when the cmdlet runs against the host itself, since both will be in the $DefaultVIServers array.
• The help for "Connect-VIServer" cmdlet mentions that "Working with a single default server is deprecated and will be removed in a future release.", so the time is now to familiarize one's self with multiple VIServer behavior.
  
• As the message in the Powershell session above reads, one can adjust the single/multiple VIServer behavior using the "Set-PowerCLIConfiguration" cmdlet, for which the help is straightforward.

Additionally, as you will probably notice, the title bar of your PowerShell session indicate that you are connected to X number of servers, along with their names.

A simple example of the usefulness of this new feature: connect to several non-vCenter managed VIServers and act against all items associated with said hosts. We are using a Powershell Credential object in this example so as not to need to enter credentials for each host (which assumes that there is a common account across them all) and to remove the need to specify credentials on the command-line.

Connect to serveral hosts

...
PS C:\> $credRootUser = Get-Credential -Credential root

Windows PowerShell Credential Request
Enter your credentials.
Password for user root: *************


PS C:\> Connect-VIServer -Credential $credRootUser -Server hst0,host1,aHost23,hst45

Name                                    Port                       User
----                                    ----                       ----
hst0                                    443                        root
host1                                   443                        root
aHost23                                 443                        root
hst45                                   443                        root


PS C:\> Get-VM -server hst0

Name                 PowerState Num CPUs Memory (MB)
----                 ---------- -------- -----------
win7test             PoweredOff 1        1024


PS C:\> Get-VM | Format-Table Name, PowerState, NumCPU, MemoryMB, @{Label="HostName"; Expression={$_.Host.Name}}

Name                 PowerState Num CPUs Memory (MB) HostName
----                 ---------- -------- ----------- --------
win7test             PoweredOff 1        2048        hst0
dubuntu0             PoweredOn  1        768         host1
dubuntu8             PoweredOff 1        1024        host1
vMA4                 PoweredOff 1        512         aHost23
2k8test              PoweredOff 1        1024        hst45


PS C:\> Get-VM | Where-Object {$_.PowerState -eq "PoweredOff"} | Start-VM
...

Now connected to each host, one could perform whatever task(s) they desired. In this example, we got the VMs for one host, got the VMs for all hosts to which we were connected, and then started all powered-off VMs. Another example would be to gather VMNIC info as described in the "Find Busted VMNICs" post here at vNugglets.com. Yet another example would be, as Glenn at get-admin.com points out in his "Find vCenter without vCenter" post, finding the VMHost on which the vCenter VM resides in the case that vCenter services (or the VM) are not responding properly (and, so, one cannot connect to vCenter to determine this info).
This feature is most useful for managing hosts that are not managed via a vCenter instance. Once the given hosts are connected to a vCenter, admins can run their commands against said vCenter as per usual.