find

Using Project “Onyx” to find the equivalent PowerCLI script to achieve tasks done in the vSphere Client

by

 

A few days ago someone dropped a comment on one of my blog posts asking how they could Enter an ESXi host into maintenance without migrating VMs off of it automatically using PowerCLI. The -Evacuate switch for the cmdlet in question (Set-VMHost) didn’t see to be working when assigning the value of $false and hence they were unable to put hosts into maintenance mode without evacuating VMs first with PowerCLI.

Perhaps the cmdlet was being used incorrectly, or there is a better way of doing this, but that is not the point of this post. The point of this post is to show you the power and usefulness of Project “Onyx”. Project “Onyx” is an application released (quite some time ago!) by VMware that is essentially a “script recorder”. It connects to your vCenter instance, and in turn, you connect to it as a proxy using your vSphere client. Communications are not secured when doing this, so everything you do in your vSphere client is able to be recorded. You essentially end up with a “recording” of API calls that can be utilised in PowerCLI. Where this comes in handy is where you are not able to achieve something with PowerCLI’s already huge library of cmdlets. In this case the -evacuate switch of Set-VMHost was not working the way I expected it to work, and so to avoid wasting time trying to figure out what I needed to do, I just fired up Project Onyx, connected to it via the vSphere Client, then told an ESXi host to enter maintenance mode (unticking the migrate powered off / suspended VMs option of course) whilst the Project Onyx application was set to “record” mode.

The console then collected the necessary script, and I just modified it as necessary to create a small script that did the exact same task, but this time in PowerCLI.

 

To use Project “Onyx” simply download it from this page, then run the executable once you have extracted the .zip file. Tell Onyx to connect to your vCenter Server, then use your vSphere Client to connect to the machine that Onyx is running on (IP). Make sure you specify the correct listening port in the vSphere Client connection too – it will be the port listed in the Window Title bar of the actual Project “Onyx” application when it is running. Click the record button in the Application and then perform the required tasks using the vSphere Client.

 

Project Onyx application window with some recorded script. Note the port 1545 in the Window Title Bar.

 

Connecting to Onyx as a proxy

 

 

Finding Vendor specific VIBs on ESXi hosts with PowerCLI

by

 

Example showing VIBs loaded on a host with a search of the vendor name "VMware"

 

The other day I was trying to find a list of Custom VIBs (VMware Installation Bundles) that were installed on an ESXi host. The reason was that I just wanted to verify that the VIB had actually installed correctly or not. I threw the query out on Twitter and of course @alanrenouf had a solution in next to no time.

So Alan’s solution is to use the Get-EsxCli cmdlet and specify the host name using the VMHost parameter. After that, he simply uses the code property “software” to gain access to the list of VIBs on the host. E.g.

$ESXCLI = Get-EsxCli -VMHost esxi-01.noobs.local
$ESXCLI.software.vib.list()

I have used esxcli on its own before but didn’t realise that PowerCLI had this cmdlet built in to interface with hosts in the same way that esxcli would. This is a great solution and means you can fetch so much more in this regard.

To filter things down a bit more and find the exact match for the Dell OMSA VIB I was looking out for, I used a where clause looking for a match for “dell” on the Vendor property:

$ESXCLI.software.vib.list() | Select AcceptanceLevel,ID,InstallDate,Name,ReleaseDate,Status,Vendor,Version | Where {$_.Vendor -match "dell"}

Thanks again to Alan Renouf for pointing out the use of Get-EsxCli and for providing an example!

 

Get vCenter User Sessions and Idle times with PowerCLI

by

Today I was looking into a small “nice to have” notification system for users that had left their vSphere clients open and logged into vCenter. I found this great bit of script to list currently logged in users over at blog.vmpros.nl and thought I would expand on this in my own way to generate a handy list of logged in users and their current idle time – similar to the way the “Sessions” tab in the vSphere client displays user session information. When I got home this evening I expanded on the original script from vmpros.nl to create the following:

 

$Now = Get-Date
$Report = @()
$svcRef = new-object VMware.Vim.ManagedObjectReference
$svcRef.Type = "ServiceInstance"
$svcRef.Value = "ServiceInstance"
$serviceInstance = get-view $svcRef
$sessMgr = get-view $serviceInstance.Content.sessionManager
foreach ($sess in $sessMgr.SessionList){
   $time = $Now - $sess.LastActiveTime
   # Our time calculation returns a TimeSpan object instead of DateTime, therefore formatting needs to be done as follows:
   $SessionIdleTime = '{0:00}:{1:00}:{2:00}' -f $time.Hours, $time.Minutes, $time.Seconds
   $row = New-Object -Type PSObject -Property @{
   		Name = $sess.UserName
		LoginTime = $sess.LoginTime
		IdleTime = $SessionIdleTime
	} ## end New-Object
	$Report += $row
}
$Report

 

[download id=”6″]

 

Here is an example of the output of the script:

 

Using this bit of PowerCLI script, it should be easy for you to create your own notification system based on user session idle time, or some functionality that would disconnect idle users. Let me know if you do improve on the above, or if you have any other suggestions.

 

Can’t find/create new VMFS datastore after removing old one using Add Storage Wizard

by

 

Yesterday I was doing some out of hours work for a client who had a VM on a VMFS 3 datastore that only had a 1MB blocksize, but needed a data disk larger than 256GB. Naturally, the datastore needed to be recreated with a larger blocksize, as it is in a vSphere 4 environment and running VMFS 3. I did a storage vMotion to move the data off the datastore, then removed the datastore using one of the ESX hosts. I checked the other ESX hosts and noticed it was still showing there too. Refreshing the storage on each solved this and the datastore disappeared as expected.

 

I then went to re-create the datastore, happy with the knowledge that our SAN would still be presenting the LUN to our ESX hosts. When I arrived at the Add New Disk/LUN wizard, I saw that the LUN was in fact, not showing. Here is the troubleshooting process I used to sort this issue out. It turned out to be two old ESX hosts that were decomissioned a short while back who were still “hanging on” to this datastore.

 

  • Checked each live ESX host for the Datastore and made sure it was removed
  • Rescanned each HBA on the ESX hosts for new storage etc…
  • Tried adding datastore again (still couldn’t find the storage)
  • Logged onto FC SAN and ensured the LUN was still being presented to all ESX hosts in the cluster
  • Used vCenter “Maps” feature to select “VM to Datastore” relationship to ensure no VMs were mapping to this datastore or trying to refer to it anymore (like CDs mounted etc).
  • Under Maps, I noticed the datastore in question was still visible at the very bottom, but nothing related to it – i.e. there were no branches to anything.
  • Went to Datastores view in vCenter, and saw the datastore still listed there but had “(inactive)” next to it’s name.
  • Highlighted the datastore and looked at it’s summary (see screenshot below for example) and saw 2 x ESX hosts still showing as connected to it. I then realised that these would be the old, decommissioned ESX hosts in the inventory still “holding on” to the datastore.
  • I removed these old hosts from the vCenter inventory, and the datastore was then gone. I was then able to re-create it and the presented LUN appeared in the add storage wizard as you would normally expect.
 
datastore showing as (inactive) even after removing it from all connected ESX hosts

 

2 x ESX/ESXi hosts were still connected to the old, removed storage, preventing it from being re-created (This example shows one with 5 hosts connected for reference)

 

So if you find yourself removing a datastore, and when arriving at the add new storage wizard and this LUN is not being presented back to you as an option to create a new datastore with, try the above troubleshooting steps to ensure nothing is still referencing the old, deleted datastore. Once sorted out, you should get the option back again.

 

A quick way of finding out where your FSMO roles reside

by

 

A nice and simple blog post today, based on finding out where your FSMO roles lie, using just the command prompt. This is useful in a couple of different situations, namely:

 

  • You don’t want to spend a long time using MMCs / Active Directory Users and Computers to figure out where each of the FSMO roles are.
  • You don’t have easy access to MMCs – for example you are using Windows Server 2008 Core

 

This command works on both Windows Server 2003 as well as Server 2008 / R2.

Simply type the following in your command prompt window on one of your domain controllers:
netdom query fsmo

 

Your output should be something like the following, listing the servers which hold each FSMO role.