Enterprise Admins.org

It has been nearly three months since I last posted an update to vCheck, but I haven’t forgot about the script. Here are a couple of things I have been working on:

# Version 5.44- bwuch: cleaned up comments and logging
# Version 5.43- bwuch: resolved bug with "Host Build versions in use" counter
# Version 5.42- bwuch: Added Cluster BIOS Check
# Version 5.41- bwuch: Resolved PowerCLI 4.1 warning on line 1327 re: LunPath

5.41 – In response to a comment on vCheck 5.40, I’ve added a bug fix on what used to be line 1327. This bug fix prevents a warning when checking LUN Paths with the 4.1.1 version of PowerCLI.
5.42 – This is a newly added check that I thought was important. It validates that all nodes in a HA/DRS cluster are running the same BIOS versions. I’ve had a problem with BIOS updates causing PSODs and a specific issue with Dell blades where vMotion failed on one node of a cluster that had a newer BIOS than the other nodes.
5.43 – this is a minor cosmetic fix on the check for ESX/ESXi versions in use; when only one version was in use the counter in the header showed the number of hosts instead of the number of versions. This has been resolved.
5.44 – the console logging (using the Write-CustomOut function) was being called outside of the checks in certain cases. This caused the console to report checks were being performed that were not. This has been resolved. Additionally some unneeded code (which had been commented in several versions) has been removed from the code base.

You can download the updated version here: vCheck5.44.ps1
Please feel free to leave a comment with any suggestions or problems you may encounter.

I was looking through the vCheck Feature Request tracking spreadsheet that I’ve been working on for several months.  I found this comment that was originally posted in September 2010:

One of the Heading in the scripts says number of Inactive machines. What exactly it means that the machines are turned of or what. Secondly it doesnt list those VM’s. Can i have code for that please. Regards

Reviewing the code today, it appears this section was added back in the 1.14 version. The ‘Inactive VM’ section is simply a count of powered off virtual machines.  The following code will produce the actual list:

$FullVM = Get-View -ViewType VirtualMachine | Where {-not $_.Config.Template}
$FullVM | where { $_.Runtime.PowerState -eq "poweredOff" }

In version 5.35, a section title “Powered off VMs” was added that includes the last power on event time for each powered off server. I hope this helps!

A few weeks ago I updated the BIOS on several Dell R810 servers running ESXi 4.1U1. After applying the update I disabled the C-States and C1E settings as described here: http://enterpriseadmins.org/blog/virtualization/vmware-esxi-psod-on-dell-server/. Once I had all my updates completed, I wanted to validate that each host was reporting the latest BIOS version. A quick search of the PowerCLI forums turned up this article where @LucD had already provided the required code http://communities.vmware.com/message/1785476

Get-View -ViewType HostSystem | Select Name,@{N="BIOS version";E={$_.Hardware.BiosInfo.BiosVersion}},    
   @{N="BIOS date";E={$_.Hardware.BiosInfo.releaseDate}}

I ran into problems where only 3 of 16 hosts reported any BIOS Version. A little more searching, and I found some code that looks like someone else had encountered the same issue: http://www.sandfordit.com/vwiki/index.php?title=VI_Toolkit_(PowerShell). In the referenced WIKI article, the author checked the Hardware.BiosInfo, and if it wasn’t available they parsed Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo. This second method worked on all 16 of 16 hosts I was interested in (sample code below):

$report = @()
Get-View -ViewType HostSystem | %{ 
     $row = "" |Select Name, "BIOS Version", "BIOS Date"
     $row.name = $_.name
     $biosTemp = ((($_.Runtime.HealthSystemRuntime.SystemHealthInfo.NumericSensorInfo | Where {$_.Name -like "*BIOS*"}).Name -split "BIOS ")[1] -split " ")
     $row."BIOS Version" = $biosTemp[0]
     $row."BIOS Date" = $biosTemp[1]
     $report += $row
}
$report

This code block is on the road map for a future release of vCheck. I’m actually planning to only show clusters that contain hosts with different BIOS versions; if the cluster is good there shouldn’t be a reason to report on the issue.

Last week the Indianapolis VMware User Group hosted the 4th annual Demo Days event. I had the privilege of working with Ryan Birk (@rlbindy) and Jake Robinson (@jakerobinson) on the PowerCLI self paced lab. The purpose of this lab was to introduce people to vSphere management with PowerCLI, provide some examples to get you hooked, but not take up a lot of time (people wanted to hear expert speakers such as Scott Lowe, Mike Laverick, David Davis and Vaughn Stewart who had gathered for this event).

Jake created the following diagram of the vApp used in the labs:

As you can see, the lab consisted of a vCenter server, two virtualized ESXi hosts and a virtual shared storage appliance. Each seat in the lab connected over Remote Desktop to the vCenter server in a dedicated vApp:

We plan to make the content of this self paced lab available to everyone as soon as we work out some typos. Hopefully this should happen in the next week or so.

A special thanks goes to Bluelock (www.bluelock.com) for providing the virtual data center services and 10zig Technology (www.10zig.com) for providing the thin client devices.

I came across this article: http://blogs.vmware.com/vipowershell/2011/06/how-to-speed-up-the-execution-of-the-first-powercli-cmdlet.html and decided to test the steps out myself:

[cc lang=”dos”]
REM View the following link for details: http://blogs.vmware.com/vipowershell/2011/06/how-to-speed-up-the-execution-of-the-first-powercli-cmdlet.html

C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install “VimService41.XmlSerializers, Version=4.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”
C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install “VimService40.XmlSerializers, Version=4.0.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”
C:\Windows\Microsoft.NET\Framework\v2.0.50727\ngen.exe install “VimService25.XmlSerializers, Version=2.5.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”

REM If you are running on 64-bit OS, you need to run the following as well:
if %PROCESSOR_ARCHITECTURE% == AMD64 (
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install “VimService41.XmlSerializers, Version=4.1.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install “VimService40.XmlSerializers, Version=4.0.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”
C:\Windows\Microsoft.NET\Framework64\v2.0.50727\ngen.exe install “VimService25.XmlSerializers, Version=2.5.0.0, Culture=neutral, PublicKeyToken=10980b081e887e9f”
)
[/cc]

Running the NGEN.EXE commands made my connect-viserver cmdlet run a bit faster…it now takes 8 seconds the first time instead of 12. Not much savings, but if I had time to waste I wouldn’t be using PowerCLI in the first place!