WilliamLam.com

How to get rid of "Quicks stats on hostX is not up-to-date" message

by // 10 Comments

After upgrading my Apple Mac Mini to ESXi 5.5 I noticed the following warning message being displayed after joining my ESXi host to my vCenter Server:

"Quick stats on mini is not up-to-date" 

I have seen this warning message in the past and it usually goes away within a few minutes of connecting to a vCenter Server. However, this time it did not go away and as you can see from the screenshot, I have had my ESXi host up for 4 days now and the message is still there.

UPDATE (9/30) - This looks to be a known issue in vSphere 5.5 and there is a permanent fix which has been documented in the following VMware KB 2061008. Restarting the management service will not prevent the warning message from coming again, please refer to the KB for the solution.

I do not know about you, but I like to have a clean environment and I get annoyed when I see warning/error messages in the UI. From what I can tell, vCenter Server was able to collect the "quick stats" from the ESXi host but perhaps there was a communication problem at some point or just a glitch?

In any case, is is pretty easy to fix the problem, you just need to restart the management service on the ESXi host and this will force a refresh of the stats. You have three ways of doing this:

  1. Restart management service using DCUI connecting to your ESXi console
  2. Restart management service using DCUI via command-line
  3. Restart management service using command-line script

Option 1 is pretty straight forward and both Option 2 and 3 can be performed on the command-line via an SSH session to your ESXi host if you have enabled SSH.

Option 2 - To launch the DCUI, just type "dcui" on the command-line and you will be able to interact with the DCUI as you normally would from the console and restart the management service:

Option 3 - To restart just using the command-line, you can run the following command to restrat the management service:

/sbin/services.sh restart

Quick Tip: New Hyper-V guestOS identifier in vSphere 5.5

by // 16 Comments

For those of you who are so inclined to run Hyper-V as a nested VM on ESXi 5.5 (not sure why anyone would want to do such a thing), you should be aware that there is a new guestOS identifier that you can configure your VM to for the most optimal configuration. The main reasons you would want to use this configuration is that by default Windows Enlightenment is enabled and this will prevent Hyper-V from running as it will detect it is running inside of a VM. This configuration will disable Windows Enlightenment to allow you to run Hyper-V.

I noticed a new guestOS identifier called "windowsHyperVGuest" while browsing through the vSphere 5.5 API Reference guide, but when I checked the vSphere Web Client, I did not see this guestOS type as an available option. Perhaps this was not a supported guestOS, after all Nested Virtualization is not officially supported by VMware. In any case, you can still configure your VM by leveraging the vSphere API.

Here is a quick vSphere SDK for Perl script called changeGuestOSID.pl which allows you to reconfigure a VM with a valid guestOS identifier from the vSphere API Reference guide. You can of course easily do this using PowerCLI as well as any other language that can speak to the vSphere API.

Once updated, you should now see it reflected in both the vSphere Web/C# Client:

Note: I did not do extensive testing other than basic installation of latest Hyper-V Server and I do not believe you need any additional settings. If you wish to run nested 64-bit VMs, then you will need to enable VHV.

Additional steps required to completely disable VSAN on ESXi host

by // 11 Comments

Something that I had noticed while working with VSAN in my lab is that when you disable VSAN on your vSphere Cluster, the disks that were used for VSAN in each of the ESXi hosts were no longer available for use afterwards. If you want to use one of the disks for creating a regular VMFS volume or even use it for for vSphere Flash Read Cache, the disks would not show up as an available device. The reason this is occurring is that the disks still contains a VSAN partition and this is not automatically removed when disabling VSAN.

You can view the partition details by using the partedUtil and specifying the "getptbl" option and the device.

Now I could use partedUtil to clear the partition, but there is actually a nice ESXCLI command that can be used to remove the disks used in a VSAN disk group and this will automatically clear the VSAN partition. The ESXCLI command is:

esxcli vsan storage remove -s [SSD-DEVICE-ID]

When I tried to run the command, I was surprised to get the following error message:

Unable to remove device: Can not destroy disk group for SSD naa.6000c29c581358c23dcd2ca6284eec79 : storage auto claim mode is enabled

It turns out when you use "Automatic" claiming mode when enabling VSAN on your vSphere Cluster, that configuration is left enabled on the ESXi host even when disabling VSAN. This then prevents you from destroying the disk group. So there is an extra step required if you choose automatic mode and you will need to run the following ESXCLI command to disable it:

esxcli vsan storage automode set --enabled false

If you are not sure, you can always perform a "get" operation to check whether automatic claim mode is enabled. Once that has been disabled, you will now be able to destroy the diskgroup by running the original command above:

The remove operation only requires the SSD device front-ending the VSAN disk group and you can identify the SSD by running "esxcli vsan storage list". I did find it odd that disabling VSAN in your vSphere Cluster did not completely disable the automatic mode on the ESXi host and I have already filed a bug request to get that fix.