WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
  • VKS
  • Homelab
    • Resources
    • Nested Virtualization
  • VMware Nostalgia
  • Apple

Search Results for: nested esxi

Handy VSAN VOBs for creating vCenter Alarms

04.22.2014 by William Lam // 3 Comments

There have been quite a few questions lately around vCenter Server Alarms for VSAN, one in particular that I have noticed is around individual disk failure for VSAN. Outside of the generic default datastore alarms, there seems to be only two VSAN specific alarms:

vsan-default-alarms
I figure there must be other useful alarms that we could create, especially after showing how you can create a vCenter Server Alarm to monitor the VSAN component count threshold based on a particular VSAN VOB. I took a look around and found the following VSAN specific VOBs which could be useful for creating additional vCenter Alarms.

VOB ID VOB Description
esx.audit.vsan.clustering.enabled VSAN clustering services have been enabled.
esx.clear.vob.vsan.pdl.online VSAN device has come online.
esx.clear.vsan.clustering.enabled VSAN clustering services have now been enabled.
esx.clear.vsan.vsan.network.available VSAN now has at least one active network configuration.
esx.clear.vsan.vsan.vmknic.ready A previously reported vmknic now has a valid IP.
esx.problem.vob.vsan.lsom.componentthreshold VSAN Node: Near node component count limit.
esx.problem.vob.vsan.lsom.diskerror VSAN device is under permanent error.
esx.problem.vob.vsan.lsom.diskgrouplimit Failed to create a new disk group.
esx.problem.vob.vsan.lsom.disklimit Failed to add disk to disk group.
esx.problem.vob.vsan.pdl.offline VSAN device has gone offline.
esx.problem.vsan.clustering.disabled VSAN clustering services have been disabled.
esx.problem.vsan.lsom.congestionthreshold VSAN device Memory/SSD congestion has changed.
esx.problem.vsan.net.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. Network is not ready.
esx.problem.vsan.net.redundancy.lost VSAN doesn't haven any redundancy in its network configuration.
esx.problem.vsan.net.redundancy.reduced VSAN is operating on reduced network redundancy.
esx.problem.vsan.no.network.connectivity VSAN doesn't have any networking configuration for use.
esx.problem.vsan.vmknic.not.ready A vmknic added to VSAN network configuration doesn't have valid IP. It will not be in use.

Looking at the list above, the following two VOBs seems like they would be useful for alerting on a disk failure is:

  • esx.problem.vob.vsan.lsom.diskerror
  • esx.problem.vob.vsan.pdl.offline

Disclaimer: There are no guarantees that a disk error or failure will automatically trigger these VOBs due to the unknown nature of how a disk may be fail, especially if it is intermittently.

Even though we can not simulate a disk error on a physical disk, we can still do some magic using a Nested VSAN environment. The worse case scenario that you could run into is that one of the disk just goes completely offline. We can simulate a similar behavior in a Nested ESXi environment by removing one of the virtual disks from the Virtual Machine (not deleting it).

To demonstrate the following scenario, here are the steps to create a vCenter Alarm for the following two VOBs:

Step 1 - Create a new vCenter Alarm and give it a name. Select “Hosts” for Monitor and “Specific event occurring …” for Monitor:

vsan-disk-failure-alarm-0
Step 2 - Add the following two VOBs above into the Event trigger:

vsan-disk-failure-alarm-1
Step 3 - Remove one of the Virtual Disks (SSD/MD) from the Virtual Machine running the Nested ESXi VM.

Step 4 - There are two ways in which you can trigger the alarm. You can either create a new Virtual Machine which will try to write to the Nested ESXi VM in which you remove the Virtual Disk or you can rescan the storage adapter for the Nested ESXi VM. In my environment, I happen to have a VM running on an NFS datastore and I performed a Storage vMotion of the VM onto my VSAN Datastore using the default FTT=1 policy on a three node VSAN Cluster. This immediately triggered the alarm as seen in the screenshots below:

vsan-disk-failure-alarm-2

vsan-disk-failure-alarm-3

Categories // VSAN, vSphere 5.5 Tags // alarm, ESXi 5.5, vob, VSAN, vSphere 5.5

How to automatically monitor VSAN Component threshold using a vCenter Alarm?

04.14.2014 by William Lam // 6 Comments

There was an interesting VMware KB article that was shared by Ron Oglesby last week which had caught my eye.

vsan-component-threshold
I had noticed earlier in the week that Ron was interested in finding the current VSAN Component count which is exposed in a variety of interfaces: RVC (vSphere Ruby Console) available on both Windows and Linux as well as through the vSphere API. I even created some recent scripts here and here using the vSphere API to remotely query the number of VSAN components for each ESXi host. I much prefer this option from a management standpoint and not have to log into each individual ESXi host.

After looking at VMware KB 2071379, I can see why Ron had asked his question as I also felt the KB was incomplete. However, to the unsuspecting eye it may not be obvious but the KB actually does contain the answer but it does not really go into any details that can be consumed by a customer. In the article, it mentions that VSAN has the ability to trigger an alarm when the threshold of the number of VSAN components on a particular host has reached 80%. What the article lacks are the details of how and where this alarm is triggered. First off, the alarm mentioned here is for vCenter Server. Secondly, this is made possible through the use of the VOB (VMkernel Observation) ID mentioned in the article. You can actually create vCenter alarms based on these ESXi host generated VOBs which I have written about in the past such as this one on detecting duplicate IP Address for your ESXi hosts. The process in creating this vCenter Alarm is pretty straight forward and I agree that this alarm should have been created by default (something I will raise internally with the engineering team).

Here are the steps to create a vCenter Server Alarm to notify at the 80% VSAN Component threshold:

Step 1 - Create a new vCenter Server Alarm and give it a name and select "Monitor specific event ..." for a Host and make sure it is enabled.

Screen Shot 2014-04-11 at 4.41.27 AM
Step 2 - Add in esx.problem.vob.vsan.lsom.componentthreshold for the Event

Screen Shot 2014-04-11 at 4.42.01 AM
Step 3 - You can leave the actions to be empty which will just generate a regular vSphere Alarm or you can specify an action.

Once we have our vCenter Alarm created, we will probably want to test and verify the alarm is working using either a Nested ESXi VSAN environment or an actual VSAN environment. The next question is how do we go about creating 2400 VSAN components? Well, instead of manually creating 2400 VMs which will probably take awhile, we can easily do so by leveraging a neat little utility found in the ESXi Shell called /usr/lib/vmware/osfs/bin/objtool

Disclaimer: The tools and scripts used in this article is mainly for education and information purposes The command below will create an object called object-1 with size 1KB leveraging the VSAN Policy of hostFailuresToTolerate=0 & forceProvisioning=1:

/usr/lib/vmware/osfs/bin/objtool create -s 1KB -a 3 -n object-1 -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))"

For this particular test, we just want to quickly create 2400 VSAN components. To do so, you will need about 32GB of memory to reach the maximum amount of supported VSAN Components. This should not be a problem for a "real" VSAN environment but for my Nested ESXi environment I had to increase my resources for this test. Since VSAN is a Distributed Object Store, the objects being created will be randomly placed within a VSAN Cluster. To quickly get to 2400 components, I also put 2 out 3 ESXi hosts into Maintenance Mode to ensure all objects are created o the first ESXi host.

vsan-component-count-alarm-3
Finally, to assist with the creation of these VSAN Objects automatically, I created a quick script which you can run in the ESXi Shell

#!/bin/sh

START=1
END=2400

for i in $(seq ${START} ${END});
do
	echo "Creating VSAN Component ${i} ..."
	RES=$(/usr/lib/vmware/osfs/bin/objtool create -s 1KB -a 3 -n object-${i} -p "((\"hostFailuresToTolerate\" i0) (\"forceProvisioning\" i1))")
	UUID=$(echo ${RES} | awk -F 'UUID:' '{print $2}')
	echo ${UUID} >> /tmp/uuid
done

The creation of each object will have an associated UUID which will be saved into a temporary file /tmp/uuid and you can use the following script to delete the object once you have confirmed the vCenter Alarm works.

#!/bin/sh

for i in $(cat /tmp/uuid);
do
	echo "Removing VSAN Object $i ..."
	/usr/lib/vmware/osfs/bin/objtool delete -u $i
done

Once the 2400 VSAN Component count has been reach, you should now see the alarm we created earlier triggering for reaching the 80% threshold.

vsan-component-count-alarm-0

Categories // VSAN, vSphere 5.5 Tags // alarm, components, objtool, vob, VSAN, vSphere 5.5

Re: Host is in a VSAN enabled cluster but does not have VSAN service enabled

03.18.2014 by William Lam // Leave a Comment

I recently noticed a couple of people hitting a warning message when configuring VSAN and specifically when running VSAN in a Nested ESXi environment (which is not officially supported by VMware). The warning message is displayed on the summary page of the ESXi host which states the following:

Host is in a VSAN enabled cluster but does not have VSAN service enabled

vsan-minimal-memory
The reason you are seeing this issue is related to the amount of memory you have allocated for your Nested ESXi VM. During the VSAN Beta, the minimal amount of memory was 4GB but it looks like that has changed to 5GB with the GA of vSphere 5.5 Update 1 last week. I know we could have done better job with the error message and communicate the actual underlying issue (will ensure we have an FR filed for this).

However, the fix is quite simple, just shutdown your Nested ESXi VM and then change it to 5GB and this message will go away. It is also worth noting that as you increase the number of disks and disk groups in your ESXi hosts, there will be an increase in memory. I would highly recommend you take a look at the official VSAN Design & Sizing guide to properly size out your real VSAN environments.

For basic functional testing and education of VSAN (not including running additional VMs), running a Nested ESXi VM with 5GB will be sufficient. You can also take a look at the my VSAN Nested ESXi OVF template which can just download and install ESXi 5.5 Update 1 without any issues.

Categories // Nested Virtualization, VSAN, vSphere 5.5 Tags // nested virtualization, VSAN, vSphere 5.5

  • « Previous Page
  • 1
  • …
  • 55
  • 56
  • 57
  • 58
  • 59
  • …
  • 67
  • Next Page »

Search

Thank Author

Author

William is Distinguished Platform Engineering Architect in the VMware Cloud Foundation (VCF) Division at Broadcom. His primary focus is helping customers and partners build, run and operate a modern Private Cloud using the VMware Cloud Foundation (VCF) platform.

Connect

  • Bluesky
  • Email
  • GitHub
  • LinkedIn
  • Mastodon
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • Programmatically accessing the Broadcom Compatibility Guide (BCG) 05/06/2025
  • Quick Tip - Validating Broadcom Download Token  05/01/2025
  • Supported chipsets for the USB Network Native Driver for ESXi Fling 04/23/2025
  • vCenter Identity Federation with Authelia 04/16/2025
  • vCenter Server Identity Federation with Kanidm 04/10/2025

Advertisment

Privacy & Cookies: This site uses cookies. By continuing to use this website, you agree to their use.
To find out more, including how to control cookies, see here: Cookie Policy

Copyright WilliamLam.com © 2025

 

Loading Comments...