Getting Network Adapter information using PowerCLI

So recently I was asked for a list of MAC addresses for all the VMs in my demo environment… Didn’t really want to do this manually by going into each VM and checking the hardware settings, so thought I’d see if I can find some PowerCLI commands that will do the job…… After a short dive into the PowerCLI reference guide I found the following commands worked:

Get-VM |
Get-NetworkAdapter |
Select-Object -property Parent, MacAddress
Format-List -Property *

mac

Note: I’m assuming you know how to use the vSphere PowerCLI Interface….. if not, you’ll need to connect to the vCenter Server in PowerCLI before running the cmdlets above!

If you don’t use the Select-Object command, it will list every property field for each of the network adapters, as I only wanted the VM name and MAC address, those were the properties that I chose.

You can even output the info to a txt file by adding the > c:\xxx.txt after the Select-Object command line, or even output to a csx file (using | Export-csv c:\xxx.csv)

Protecting your Cloud (vCloud & SRM)

So one of the BIG problems at the moment is that SRM does not fully support protecting your vCloud environment.
http://www.vmware.com/support/srm/srm-releasenotes-5-1-1.html#caveats

It supports protecting your management cluster (so the vCenter servers, vCD cells, vCNS manager, vCM, DBs, etc), but it doesn’t yet protect your resource cluster….. so all those VMs you’ve deployed in your organisations under vCD – well they’re not protected by SRM!

Definitely NOT COOL if your primary site goes tits up!!

From what I can gather, this is mainly due to the way SRM work….. When you setup SRM for DR, you have to ‘pre-create’ resources at the recovery site in order to map the resources from the protected site to them (stuff like resource pools, folders, network, placeholder VMs). Unfortunately vCD likes to have full control of a resource cluster and manages all the resource itself – this basically means that the vCD cells are not aware of the objects that have been created in the recovery site for SRM. It doesn’t matter if the names are the same, what matters is the Management object Reference IDs (MoRef ID) have changed and this is what vCD uses to construct its environment…..

MoRef IDs are used to correlate objects between vCD and the underlying vSphere/vCenter layer. Any changes to these identifiers will result in the loss of functionality because vCD will not be able to manage these objects as it will not be aware of them (ie the MoRef IDs will not exist inside the vCD DB).
The use of SRM would result in a change of the MoRef ID on the vCenter Server layer, resulting in an incorrect reference in the vCD database – and so leaving the object (eg. a VM) unmanageable from a vCD perspective. I believe SRM also re-signatures the storage volumes which will also confuse vCD.

About a year ago Chris Colotti and Duncan Epping wrote an article on how vCloud DR could be achieved, this involved the clever idea of putting the resource ESXi hosts at the recovery site into the same resource cluster as the resource ESXi hosts at the protected site (but in maintenance mode as obviously it won’t see the storage located at the protected site so can’t be used by vCD). Then using vSphere HA to take the ESXi hosts out of maintenance mode to handle the recovered workloads…. However, this solution did involved manual intervention to fail over the vCD resources correctly:
http://www.yellow-bricks.com/2012/02/13/vcloud-director-infrastructure-resiliency-solution/
http://www.vmware.com/files/pdf/techpaper/vcloud-director-infrastructure-resiliency.pdf

Earlier this year, another white paper was released which described how the majority of this manual process (ie the VMware bits) could be automated using PowerCLI:
http://www.vmware.com/files/pdf/techpaper/VMware-vCloud-Directore-Infrastructure-resiliency-whitepaper.pdf

However, what’s missing is the automation of the whole storage piece – breaking the replication and making the volumes read/write….. but then I guess this is really more storage-vendor dependent! =)
I guess if the storage vendor has exposed the array to VMware using VASA then it could be possible to script the storage steps as well….! =)

Anyways, it’s been an interesting read…… and definitely a problem I see VMware sorting out for the next release of SRM!

Given how powerful PowerCLI is, I really need to find some time to learn how to use it!!

Using PowerCLi to run a ESXCli command to find storage info

So recently I had to use VMware Health Analyzer in order to run a health check on a clients’ virtual environment alongside a colleague who was running Navisphere Analyzer against the clients’ EMC storage array.

We notice a slight problem where we couldn’t match up the LUN IDs from the storage (ie Channel:Target:Lun – which VMware refers to as Runtime name) and the UUIDs that are used in VMware (ie naa.xxxxxxx).

The Health Analyzer outputs only datastore/LUN information referencing the appropriate UUID. The EMC nar file generated outputs only LUN information referencing the appropriate LUN ID (well that’s what my colleague says – if anyone knows how to generate data using the VMware UUID then please let me know!).

So we pretty much had no reference to match up VMware Health Analyzer LUN data to the EMC Navisphere Analyzer LUN data…….

So a quick google sent me looking here:

http://www.geekmungus.co.uk/vmware/matchvmwarelunidtoemcsanlunid

But that would only be useful if you are able to sit on site and look at the vSphere Client/Navisphere GUI, plus it would be quite a tedious process to go through all the LUNs.

Sooooo…. after a lot of trial and error, and googling PowerCLI commands, I ended up writing the following script (with a little help from Luke’s scripts at http://thephuck.com/):

param([string[]]$vmhosts = $null)
#By default, PowerShells execution policy is set to Restricted; that means that scripts will not run.
#RemoteSigned allows PowerShell to run any scripts you write, but only run scripts from the Internet if they have been signed by a trusted publisher.
Set-ExecutionPolicy RemoteSigned
Add-PSSnapin VMware.VimAutomation.Core -ErrorAction SilentlyContinue #required if running from normal Windows PowerShell and not VMware Powershell

function usage()
{
Write-host "This script is used to pull Storage information for all hosts provided."
Write-host "You can specify -vmhosts as an array:"
write-host "Get-LUN.ps1 -vmhosts (`"host1`",`"host2`",`"host3`")"
}

if ($vmhosts -eq $null)
#Checks to see if vmhosts parameter has been supplied when script is run
{
usage
break
}

if ($vmhosts -ne $null)
{
#Credentials required for ESX hosts - assuming credentials will be same for all ESX hosts
$vmhost_creds = $host.ui.PromptForCredential("ESX/ESXi Credentials Required", "Please enter credentials to log into the ESX/ESXi host.", "", "")
foreach ($vmhost in $vmhosts)
{
connect-viserver $vmhost -credential $vmhost_creds > $NULL 2>&1
$esxcli = Get-EsxCli -VMHost $vmhost
#Outputs the data into a text file located in C:\ and will name the file using the host name
$esxcli.storage.core.path.list() | Out-File c:\$vmhost.txt
disconnect-viserver -confirm:$false
}
}

#garbage collection
$vmhost_creds = $null
$vmhosts = $null
$esxcli = $null

 

So basically cut and paste the code into notepad and save it as Get_LUN.ps1 and run from a PowerShell console…….

The output will list all Adapters, UUIDs, Runtime Names, Identifiers, etc for the host.

 

If you want to limit the data obtained, then you could always pipe the data through a select filter before piping it to the output file….. so a bit like: $esxcli.storage.core.path.list() | Select Adapter,Device,RuntimeName,Transport | Out-File c:\$vmhost.txt