Generating Graphical Charts with VMware PowerCLI & PowerShell

Charts are awesome – they can help make sense of endless reams of text and data and they generally look pretty. So my question to myself was: “How do I get useful data I generate using PowerCLI into a nice, neat little chart?” I had a quick google and found a couple of different solutions. The one that stood out as being the easiest to start off with for me was to use the “Microsoft Chart Controls for Microsoft .NET Framework 3.5

I read a few blog posts around detailing how to create these custom .NET charts in PowerShell, but this tends to be quite a tedious process – akin to creating a Windows Forms GUI in PowerShell manually – basically a complete pain. The blog posts I read definitely helped me understand how to create charts and soon I was able to generate some pretty cool charts based off data from PowerCLI (or PowerShell) data. I wanted to ultimately automate the creation of Charts for my PowerCLI and PowerShell scripts, so I decided to create myself a Function that could be used anywhere to generate a Bar or Pie Chart on the fly.

httpv://youtube.com/watch?v=EvQ2znWr0lk

Enter Create-Chart. This is the Function I have made that accepts a bunch of Parameters to create a custom Chart and outputs this to a .PNG file. The data needs to be fed in to the function via a Hash Table (this could be changed) so I also created a “helper” Function called Create-HashTable which also does the work of generating a hash table for use with the Create-Chart Function. You could of course also just feed the Create-Chart function with a manually created HashTable too – this is useful to know because my Create-HashTable function is fairly basic and is not too flexible. Here are a couple of examples of Charts I created using these Functions:

Pie Chart of VMs and their configured Memory Resource settings
The same data but now in a Bar chart
Host Chart created with a manually created Hash Table (Name and MemoryUsageMB Properties)

Download the two functions below to give them a try! Please do suggest any improvements – my parameter handling on the Create-Chart script needs work – they are not specified as mandatory, although all parameters are mandatory – I couldn’t get the Function to work correctly when I did make them mandatory. The Create-HashTable function could also be improved in that at the moment you can only specify Cmdlets for the “Cmdlet” parameter that do not have any double quotation marks inside the cmdlet or any $_ variables. This is because of the way I am using the Invoke-Expression cmdlet inside the function. A simple cmdlet parameter such as “Get-VM | Select Name, MemoryMB” would work just fine for example. Remember that the Create-Chart function needs to be fed with a Hash Table. This could be generated yourself, or by using the Create-HashTable function below. Here are the downloads:

Don’t forget the Microsoft Chart Controls – a requirement to run these functions
Download the functions here:

https://www.shogan.co.uk/wp-content/uploads/Create-Chart.zip

https://www.shogan.co.uk/wp-content/uploads/Create-HashTable.zip

Once you have the Functions loaded, here are some examples to show you how to use them:

Pie Chart of VMs and their MemoryMB setting:

Create-Chart -ChartType Pie -ChartTitle "Sean's Awesome VM Chart" -FileName seanchart3 -XAxisName "VMs" -YAxisName "MemoryMB" -ChartWidth 750 -ChartHeight 650 -DataHashTable (Create-HashTable -Cmdlet "Get-VM" -NameProperty Name -ValueProperty MemoryMB)

Bar Chart of ESXi Hosts and their Memory Usage (MB) values:

Create-Chart -ChartType Bar -ChartTitle "Sean's Awesome Host Chart" -FileName seanchart4 -XAxisName "VM Hosts" -YAxisName "Memory Usage (MB)" -ChartWidth 750 -ChartHeight 650 -DataHashTable (Create-HashTable -Cmdlet "Get-VMHost" -NameProperty Name -ValueProperty MemoryUsageMB)

Use your own Hash Table to input the data:

Create-Chart -ChartType Bar -ChartTitle "Custom Chart" -FileName seanchart5 -XAxisName "My Objects" -YAxisName "My Object Values" -ChartWidth 750 -ChartHeight 650 -DataHashTable $HashTable

So there you have it – a fairly easy way to Chart the data you can get from your PowerCLI or PowerShell cmdlets! I wrote these Functions as part of a larger report that I am working on for another soon to come blog post! As I mentioned above, there is plenty of room for improvement – so if you do make any improvements or changes, please be sure to post them in the comments section.

Checking that a VM has the VMware Balloon driver running with esxtop

 

To check that your VMs have loaded and are running the VMware Memory Balloon driver in the guest OS, you can use esxtop.

 

  • Connect to your ESXi host using vMA, the DCUI or PuTTy (needs SSH service running) and run esxtop.
  • Switch to the Memory page (press M)
  • Press F to add a field
  • Press J to add the field “MCTL = MEM Ctl (MB)”
  • Press space to return to the main memory view page of esxtop.
  • In the new MCTL? column, look at the list of VMs – a “Y”  means that the driver is loaded and running whereas a “N” means that the balloon driver is not present.

 

This can be useful to double check things if you run into a problem troubleshooting memory ballooning issues as I have seen cases where VMware Tools reports as “OK” for the VM but the balloon driver is not running when viewed in esxtop.

 

 

Troubleshooting & Fixing VMware Host Profile errors

 

Synopsis

 

Trying to apply a Host profile created from another Host in a cluster today I got an error message which resulted in only some of the host profile actually being applied.

 

A specifed parameter was not correct. changedValue.key

 

Error message received after trying to apply profile to Host

 

I thought that the error message looked familiar, but couldn’t quite remember at the time, so I left what I was doing to take a look at again later. On my way home this evening I had a bit of a brainwave – the ESX host I had taken the original profile from was a slightly different update level (2) as opposed to the update level of the newer host I was applying the profile to. I also remembered where I had seen the text “changedValue.key” in the error message before – changing Advanced Settings on a Host using PowerCLI! This gave me a good idea as to where to look for the issue I was having with this Host Profile – the Advanced Settings in the Host Profile.

 

I knew it was probably to do with a value that was different between hosts because of their differing update levels, but to gather more information I decided to hit the log files to find out more… Opening up /var/log/vmware/hostd.log on the Host and navigating down to the time I tried to apply the Host Profile I found this (interesting bit in the screenshot below, full log text in the section after that):

 

Interesting bits of information that help point to the issue in hostd.log

 

[2012-02-20 19:50:07.849 F66966D0 info 'TaskManager'] Task Created : haTask-ha-host-vim.option.OptionManager.updateValues-896
[2012-02-20 19:50:07.853 F66966D0 verbose 'VersionOptionProvider'] Attempt to set readonly option
[2012-02-20 19:50:07.853 F66966D0 info 'App'] AdapterServer caught exception: vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'TaskManager'] Task Completed : haTask-ha-host-vim.option.OptionManager.updateValues-896 Status error
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Activation [N5Vmomi10ActivationE:0x5cf27a98] : Invoke done [updateValues] on [vim.option.OptionManager:ha-adv-options]
[2012-02-20 19:50:07.853 F66966D0 verbose 'Vmomi'] Arg changedValue:
(vim.option.OptionValue) [
   (vim.option.OptionValue) {
      dynamicType = <unset>,
      key = "Misc.HostAgentUpdateLevel",
      value = "2",
   },
   (vim.option.OptionValue) {
      dynamicType = <unset>,
      key = "Misc.HostAgentUpdateLevel",
      value = "2",
   }
]
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Throw vmodl.fault.InvalidArgument
[2012-02-20 19:50:07.853 F66966D0 info 'Vmomi'] Result:
(vmodl.fault.InvalidArgument) {
   dynamicType = <unset>,
   faultCause = (vmodl.MethodFault) null,
   invalidProperty = "changedValue.key",
   msg = "",
}
[root@hostnamehere vmware]#

 

The cause:

 

So we can see that the Host Profile did a “change value” (changedValue) on the key “Misc.HostAgentUpdateLevel” and this is where our error was thrown with an “invalidProperty” (changedValue.key). If we google the message “vmodl.fault.InvalidArgument” we’ll arrive at the VMware SDK Reference Guide which states that “An InvalidArgument exception is thrown if the set of arguments passed to the function is not specified correctly.” In this case we’ll soon see that this is happening because the value that is trying to be changed is actually a read-only value for the Host – as it should be, as it just references the update level of the host – this wouldn’t normally be something you want to change.

 

The issue here was of course that original host off which the profile was based is update 2, whereas the new host having the profile applied is update 4. The two settings differ, therefore Host Profiles tries to change this value on the new Host. The setting is really read-only, therefore Host Profiles fails to apply the value and throws this error message at us, which also results in the rest of our host profile (annoyingly) not being applied. Ideally if Host Profiles found a read-only value that shouldn’t be changed, it would not change this value.

 

Solution:

 

So the simple solution is to either:

 

  • Take a Host Profile from a Host with the settings you need which is on the same update level as the Hosts you will be applying this profile to.
  • Modify this Host Profile (edit) and remove the Advanced Setting for “Misc.HostAgentUpdateLevel“.

 

In my case, I was testing the host profile on a clean ESX Host before using it for other Hosts – that meant I also only had one new ESX host of this particular update level and therefore couldn’t use the first option (take the profile from an existing host). So I therefore just went to Home -> Host Profiles and edited this Host Profile to get rid of the unnecessary key called “Misc.HostAgentUpdateLevel” like so:

 

Remove the two entries for "Misc.HostAgentUpdateLevel" from the Host Profile

 

After removing the entries referring to this read-only key, I simply re-applied the profile and this time around all the settings went on as expected and there was no more error message. So to sum it all up, check that you aren’t first of all taking a Host Profile from a reference host of a different update level as your target hosts (and if you have to you can then resort to manually editing your profile as I did). If you get cryptic errors applying your Host Profiles, check your Host log files for more info and clues as to where the issue may lie.

 

Create a custom Welcome Message / DCUI Splash screen for your ESXi Hosts with esxcli

 

Messing around with ESXCLI the other day I came across the commands to get / set the welcome message for your ESXi host. By default you are greeted with the following familiar splash screen for your ESXi hosts:

 

Standard DCUI Splash Screen / Welcome Message

 

Well, with esxcli, it turns out you can very easily change this to your own custom welcome message / splash screen. I personally don’t see any practical gains by doing this, but just thought I would show the command to set it. Using esxcli, enter the following (of course the bit between quotes is up to you):

 

esxcli system welcomemsg set -m="My Custom Welcome Screen. Press F2 to Customize System/View Logs or F12 to Shutdown/Restart."

 

 

To see what the current custom message is set to simply use the same command, but this time use “get” –

 

esxcli system welcomemsg get

 

Finally, to set it back to the default (No welcome message), simply set your welcome message to nothing –

 

esxcli system welcomemsg set -m=

 

Here is an example of a custom welcome message for an ESXi host in my lab I tested this with:

 

 

Troubleshooting VMware Update Manager errors

 

Today I was creating an upgrade baseline for some old ESX 4.x hosts to be patched up to a newer update level. I ran into an error whilst uploading an ESX ISO with the new update version and subsequently found myself troubleshooting the issue. I thought I would do a quick post on general things to check when troubleshooting VMware Update Manager.

 

  • First of all check you are of course uploading the correct file / ISO! Note that ESX upgrade baselines work with ISO files and ESXi deal with .zip files. Ensure you are using the correct file and build of ESX or ESXi depending on which you are planning on using.
  • Consult the log files! Logs are kept in different locations depending on your OS that VUM is running on.
    • Windows XP, 2000, and 2003 – C:\Documents and Settings\All Users\Application Data\VMware\VMware Update Manager\Logs
    • Windows Server 2008 and above – C:\ProgramData\VMware\VMware Update Manager\Logs\
    • ESX update manager logs are kept in – /var/log/vmware/esxupdate.log
      • use cat /var/log/vmware/esxupdate.log | more to view the log file in ESX from the shell / PuTTy SSH session.
  • The log file in Windows should be named something similar to “vmware-vum-server-log4cpp.log”
  • You should be able to locate an issue that has occurred by noting the time the issue happened in Update Manager. Open up the relevant log file and navigate down to the time it happened in your logs. Hopefully the description / entry will point you in the right direction.

 

In my case today, I was trying to upload an ESX 4.0 Update 4 ISO (Complete) to create a new Upgrade Baseline for some older ESX 4.0 hosts. I got an error after uploading the ISO using the new baseline upgrade wizard. See below:

 

Error message after uploading ISO for Host Upgrade Baseline

 

Although the message above in the GUI is not very descriptive, after looking at the log files on the Update Manager server I found an entry which explained what my problem was:

 

Importing classic ESX upgrade package from C:\WINDOWS\TEMP\vum-temp2748786559745325611upload.iso
[2012-02-14 14:28:21:100 'HostUpgradeMetadata' 14028 DEBUG]  [metadata, 682] Stamped MD5: 580834a00621d98be322deb4b31971d8
[2012-02-14 14:28:21:100 'HostUpgradeMetadata' 14028 DEBUG]  [metadata, 559] ComputeISOChecksum started...
[2012-02-14 14:28:25:026 'HostUpgradeMetadata' 14028 DEBUG]  [metadata, 597] ComputeISOChecksum finished...
[2012-02-14 14:28:25:026 'HostUpgradeMetadata' 14028 ERROR]  [metadata, 693] MD5 check failed: f7a4523e2b7312b9b0f5441f8fa1f9d5
[2012-02-14 14:28:25:026 'HostUpgradeMetadata' 14028 ERROR]  [metadata, 721] Integrity check of upgrade ISO failed

 

The problem was that my ISO file was corrupt – the download had seemed to complete just fine when downloading from vmware.com, but there must have been an issue. A quick check of the ISO using my md5sum command line utility in Windows confirmed that the MD5 hash for this ISO file did not match the MD5 hash listed for the ISO on vmware.com (as pointed out in the log files above).

 

I downloaded a fresh copy of the ISO, checked the MD5 again  to ensure it matched this time, and re-uploaded to create a new baseline. Everything worked as expected this time around.