vSphere: Get (hyperconverged) SMART information via #PowerCLI and #ESXCLI

Scooby Doo can doo-doo, but Jimmy Carter is SMARTer

Screen Shot 2016-06-13 at 13.55.55

Ok, that was weak… let’s still try to turn this blog post around to a good one and let me show you how you can be SMARTer by getting relevant SMART information out of your local disk devices within your ESXi host (Which can be really useful for vSAN / hyperconverged environments with local devices).

Thanks to Get-ESXCLI (v2) we are able to access easily the local ESXCLI tool via PowerCLI 6.3 R1++. Since there is a ESXCLI Namespace Method to access the SMART data of local disks we are going to use this in the following script.

# Change Parameter 
$vCenter = 'vcsa01.lenzker.local'
$ClusterName ='CL01'
$outputfile = 'c:\temp\smart.csv'
Connect-VIServer $vCenter
$resultList = @()
$Cluster = Get-Cluster -Name $ClusterName
$ESXs = $Cluster | Get-VMHost | Where {$_.ConnectionState -eq 'Connected'}
Foreach ($ESX in $ESXs){
$scsidevs = $ESX | Get-Scsilun | Where {$_.isLocal -eq $True -AND $_.canonicalName -notmatch 'mpx'}
$esxcli = $ESX | Get-ESXCLI -v2
$arguments = $esxcli.storage.core.device.smart.get.CreateArgs()
foreach ($scsidev in $scsidevs){
write-host "Gathering Smart-Data from $scsidev.canonicalName"
$arguments.devicename = $scsidev.canonicalName
$smart = $esxcli.storage.core.device.smart.get.Invoke($arguments)
$healthstatus = ($smart | Where {$_.Parameter -contains 'Health Status'}).Value
$readerror = ($smart | Where {$_.Parameter -like'Read Error Count'}).Value
$writeerror = ($smart | Where {$_.Parameter -contains 'Write Error Count'}).Value
$temperature = ($smart | Where {$_.Parameter -contains 'Drive Temperature'}).Value
$resultList += New-Object -TypeName PSCustomObject -Property @{
esx = $ESX.Name
devname = $arguments.devicename
healthstatus = $healthstatus
readerror = $readerror
writeerror = $writeerror
temperature = $temperature
} | Select esx, devname, healthstatus, readerror, writeerror, temperature
$resultfile = $resultList | export-csv -Path $outputfile -notype

et voila…it will discover all local devices and exports the relevant information into a CSV file.

get-smart output

you can find the script here.

Let’s learn #VMware #PowerCLI

Version 1.0 (Date: 05/April/2016)

In the second post of my let’s learn series I will try to summarize useful links, classes, lectures and recommendations for getting started with PowerCLI.


As described in my why learn #PowerCLI post, I realized during my daily job that many students/ customers are not familiar (or feeling confident enough to deal) with VMware’s PowerCLI (even though it is so so powerful). Since I know which boost it had on my VMware operational skills, I wanted to start this collection to give people a good starting point to get from $null to $pro.

Read more

Why learn VMware #PowerCLI

PowerCLI (based on Powershell) is one of those things that really boosted my productivity in the VMware field. It is an easy to use product that allows you to do incredible things within a vSphere… wait… VMware environment (it also includes cmdlets for vCloud, vRealize, View …. ). Do bulk operations? easy-as-that… Gather some data for reports? not-a-big-problem-at all… Delivering hot coffee to your desk? Okok… not that incredible things (yet)…

Nowadays I still meet so many people during my daily business that aren’t really into it or are kind of afraid of using Powershell/PowerCLI. Let me try to give you some arguments why learning PowerCLI is a great idea even though it’s principles are kind of / come close to ‘programming’ *WE-HATE-PROGRAMMING-ANGST*.

1.) Become a better admin / consultant (and even architect)

As an admin (especially from the windows world) we as administrators spent so much time configuring stuff multiple times. Doing it in a graphical user mouse-/pointer-based interface it might not just take a long time. To enable SSH on 5 ESXi hosts it would take you including the login to the webclient incredible many clicks (In the 5 hosts scenario you probably need 35 clicks, 0,3 meters of scrolling, 142 seconds in the web client).

How do we solve it with PowerCLI?

Get-VMHost | Get-VMhostService | Where-Object {$_.Key -eq “TSM-SSH”} | Start-VMHostService

Much easier, especially if you archive your helper scripts somewhere so you can re-use them when ever there is a need (I know my Github repository is small, but it’s growing)

2.) Easy to learn – hard to master

The best way to describe PowerCLI / Powershell is by comparing it with Mario Kart. One of the best (and funny) video games the world has ever seen. Why is it so? Because it is so easy to get started with that even beginners might win with a little bit of luck. But anyway, if you want to start to reach maximum goals you will realise that there is so much you can do better.

The same is applicable with PowerCLI. Instead of getting a lame ‘hello world’ output in the beginning you can really create something you are familiar with (VMs, gathering useful data, etc.).

BUT remember… Mario Kart is a game… if you lose, you lose and start all over again… In the real life you would not want to go the racetrack as a beginner and start throwing bananas at other cars (at least I hope you wouldn’t do that). Learn and increase your PowerCLI skills in test-environments and only go with it into production if you understand the impact/risk and functionality of the scripts you are using.

One-liners like Get-VM | Stop-VM can create huge service impacts within your environment with minimum effort.

3.) Getting familiar with programmatical and automation approaches

The datacenter is getting more and more complex. Every component is getting abstracted multiple times ending up in a api-programmable resource. This creates new challenges (complexity) but gives us new opportunities in forms of service delivery speed / automation. In the future it will become more and more important that proccesses/workflows needs to be created (and maintained). And no matter how you are going to implement it (Orchestrator, Powershell, etc.) – the logical way of achieving it is always the same and always related to approaches coming from the programming field.

Learning PowerCLI means getting familiar with those approaches. You need to know why we need if-/else-/switch statements. Why do we need loops. What are datatypes. What is the reason that object-oriented thinking is so valuable.

Powershell (and therefore PowerCLI) abstracts away much of the mentioned complexity, but you will still touch them from time to time. Therefore if you are curious you will get a much deeper insight every time you confront yourself with those topics.

Once you are familiar with how to logically automate specific workflows (because you created your own automation mechanisms), you don’t really care which solution the automation does.

4.) The PowerCLI community is one of the best I have seen in the tech-field

There is nothing more to say. For almost every problem someone has already created a solution and has posted it in a blog / board. So what to do? Google for PowerCLI <What you want to achieve>, e.g. PowerCLI get vCPU in a cluster

Screen Shot 2016-01-21 at 11.07.31

in 95% of the cases you will find a suitable solution (maybe you need to edit the final script a little bit) on the first page of google.

And if you don’t find a solution. Just post them to the official VMware PowerCLI community

p.s. In 4 out of 5 posts Luc Dekens will help you within 72 seconds after you have posted a question there. This guy brings so much value to the PowerCLI community. Thanks for that.

5.) For nearly every problem a script or a snippet is already available

<If you have just read passage 4) too quickly…. you should read it in more detail now ;-) >

6.) PowerCLI forces you to work more accurate

Yes PowerCLI is pretty easy, but it is also a text-based user interaction. And it’s pretty typical if you configure something via text that you need to know for 100% what you are doing (in GUIs you can more easily have a trial- and error click experience).

Planning in advance what are you going to do & having a powerful tool at your hand that can shutdown your whole environment within seconds will force you to work more accurate and think more ahead in your daily doing. A skill that is IMO very very important.

Always remember what the uncle of a good’s friend’s friend told some guy:

“With great Power(CLI) comes great responsibility”


Migration of a distributed switch (vDS) to a new vCenter (PowerCLI edition)

### UPDATE: I received some posts / comments that my approaced way does NOT work when using LACP. I haven’t had the time to get deeper into that topic, but please be aware of that fact.

Reviewing Google analytics for my old blog on vxpertise.net showed that my article a few years ago is still kind of famous.

It explains how the distributed switch import/export feature can be used to migrate existing ESXi to a new vCenter. I extended the information explained in this blog post with a few lines of PowerCLI code that makes the whole process a lot of easier/faster/less error-prone.


This requirements is raising up more and more in environments of people I deal with. Especially the awesome vCenter Server Appliance (vCSA) convinces people to create a new vCenter from scratch.

Read more

Get ready for NSX phase 0: Migrate from a vSphere Standard to a distributed switch: manual and auto

The distributed switch (vDS) is a really nice piece of software within the vSphere environment. It offers a variety of very useful features (NIOC, Health Check, Central management, LACP, LBT, Netflow, and so many (features with fancy abbreviations) more). Especially if you want to move to NSX the distributed switch is mandatory. Since analytics showed me that views about my vDS blogposts are increasing it seems that there is a demand for the vDS within our virtualized environments (it’s still an enterprise+ only feature)

Migrating from a vSphere standard switch to a distributed switch is not that complicated at all if you plan it properly. Over the years I collected a lot of (troubleshooting) experiences with the vDS. Anyway I want you to learn from my mistakes to do (not-so-daily) tasks right from the beginning.

Read more

Backup and restore ESXi via PowerCLI after a failed boot device

A few days ago I encountered the following error in the webclient of my homelab.


"Lost connectivity to the device mpx.vmhba32:C0:T0:L0 backing the boot filesystem /vmfs/devices/disk/mpx.vmhba32 :C0:T0:L0. As a result, host configuration changes will not be saved to persistent storage."

In a production environment you would now check the events of your out-of-band management component (IMM, iLO, DRAC, etc.) for a failed SD-card or USB boot device. In such a situation a reboot of the ESXi host (e.g. after doing some updates) wouldn’t be a good idea. To fix the problem we need to …

  1. replace the boot device
  2. reinstall ESXi
  3. reconfigure ESXi (in an automated PowerCLI way)

Read more