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:
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:
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.
For my 100th post, I thought I would put something totally different up. Introducing PowerCLI bot!
PowerCLI Bot
I recently purchased a Wacom Bamboo tablet and have been doodling around with it – last night I decided to create a little bot for a custom 404 error page I would like to set up for Shogan.tech. I was looking at the PowerCLI logo at the time and thought I quite liked the colour combination. Anyway, things progressed and I thought I would create a little “PowerCLI Bot” as I have recently been thoroughly enjoying working with PowerCLI and PowerShell.
I’ll be changing him a bit for my custom 404 error page so keep an eye open for his distant cousin 🙂
This is a little bit of a fun project I have been working on in bits of spare time I find. It is all written in PowerCLI 5.0 / 5.1 / PowerShell and the GUI was laid out using Primal Forms Community Edition.
Updates (17-02-2013) – version 1.3:
Hosts are retrieved using a new method (for both backup and restore options)
Updates (29-12-2012) – version 1.2:
Added ESX/ESXi host validation into utility – will now test that the host is valid and either connected or in maintenance mode before attempting backup or restore (See the script’s new “Check-VMHost” function for those interested)
Minor UI improvements
Updates (29-10-2012) – version 1.1:
This utility has been tested on ESXi 5.1 Hosts and confirmed to be able to successfully create a backup archive file of these.
Be sure your DNS is working correctly on the system you run the Backup utility on – it relies on DNS to find your ESXi hosts as they are named in the dropdown when you select the host to backup. (See comments for troubleshooting)
Restore to new hardware (force restore) option added
Fixed labels and connection box label description
What it is essentially, is a GUI that allows you to Backup ESXi 5.0 or ESXi 5.1 hosts to a destination of your choice on a local drive. It also allows you to restore ESXi Host configuration bundle backups taken, to other Hosts. I had other plans to integrate cloud storage options in (Amazon S3) as a backup target, but I thought that this doesn’t really offer anything valuable and I would just keep it relatively simple for now – therefore I have disabled this functionality. The PowerCLI script is fairly long – and I know there are plenty improvements I could make to better it and shorten the code, but for now it does the job. I have added various catches for exceptions / errors so you should get visual feedback if you have entered an invalid path, or username for example.
Anyway, hopefully this proves useful to some! As always, take care using the backup / restore functionality of this utility. The restore functionality works by first putting the ESXi host into Maintenance mode (if it isn’t already in this mode) and then applying a backup bundle to the host (Restore). The Host will reboot immediately following this. The Backup and Restore is implemented using Get-VMHostFirmware and Set-VMHostFirmware cmdlets so you can read the help descriptions for an idea on how exactly these work. The Host Backup Bundles are stored in a path of your choice and when restoring from a path the cmdlet works by looking for a bundle filename that matches the name of your ESXi host selected to restore to. Note that the file browser module I have implemented here (used to select paths) is a modification of the work done by Ravikanth Chaganti on his PowerShell Help Browser GUI. I simply adapted his code to list the contents of local drives in a tree view instead of PowerShell Help cmdlets. The only limitation here is that I have not implemented code to browse further than one level into the root of each drive. If you can provide this modification yourself, please feel free to contribute in the comments! I have just not spent the extra time to do this myself yet.
Here are a couple of quick screenshots of the Utility / GUI:
An interesting thread appeared on the VMware Community forums today under the PowerCLI section where someone asked how to find all the svMotions for the past month. LucD answered the post with the solution to get the events listed out for svMotions. I tried this out in my own environment (first of all I datastore migrated (svMotioned a couple of VMs to make sure there would be some events to find). However, I didn’t get any results back. At first I thought this may be because the event names had changed between vSphere 4 and vSphere 5.
After some looking into the last 5 events that had run by using “Get-VIEvent -MaxSamples 5” and looking at the .Info section for the svMotions, I found that their Info.DescriptionId sections were showing as “StorageResourceManager.applyRecommendation” rather than “VirtualMachine.relocate” as LucD’s script had indicated they should be. After digging some more this evening, I realised that maybe the difference was down to the fact that I was svMotioning VMs between Datastore Clusters, rather than between normal Datastores (not part of a DS Cluster). I tried svMotioning a VM to a normal Datastore, and low and behold the event’s Info.DescriptionId now appeared as “VirtualMachine.relocate”!
So the difference is kind of related to the vSphere edition (in the way that you only get SDRS / Datastore Clusters in vSphere 5. More specifically, the task/event difference is seen when using Storage vMotion to move a VM between two Datastores or two Datastore Clusters.
Migrating VMs Between two Datastore Clusters, you see the event “Apply Storage DRS Recommendations“
Migrating VMs Between two normal Datastores, or from a Datastore Cluster to a normal Datastore (or vice-versa) you see the event “Relocate virtual machine“.
Here are some screenshots to illustrate what I mean:
Recent Tasks - differences between the two svMotion scenarios
PowerCLI - listing both svMotion scenario event types
Here is the PowerCLI script used to list both types of events if you are using both (or just one of) the Datastore types – i.e. Datastore Clusters or normal Datastores. It is based off LucD’s script in the first post of this thread on VMware Communities, but just modified to also show the “Between Datastore Cluster” types of svMotions too.
