WilliamLam.com

  • About
    • About
    • Privacy
  • VMware Cloud Foundation
    • VMware Cloud Foundation 9.1
    • VMware Cloud Foundation 9.0
  • VKS
  • Homelab
    • Hardware Options
    • Hardware Reviews
    • Lab Deployment Scripts
    • Nested Virtualization
    • Homelab Podcasts
  • VMware Nostalgia
  • Apple

How to configure SMP-FT using Nested ESXi in vSphere 6?

03.06.2015 by William Lam // 1 Comment

Symmetric Multi-Processing Fault Tolerance (SMP-FT) has been a long-awaited feature by many VMware customers. With the release of vSphere 6.0, the SMP-FT capability is now finally available and if you want to try out this new feature and see how it works from a "functional" perspective, you can easily do so by running it in a Nested ESXi environment. SMP-FT no longer uses the "record/replay" capability like its younger brother Uniprocessing Fault Tolerance (UP-FT). Instead, SMP-FT now uses a new Fast Checkpointing technique which not only improves the overall performance of its predecessor but also greatly simplifies and reduces additional configurations when running in a Nested ESXi environment.

Disclaimer: Running SMP-FT in a Nested ESXi environment does not replace or substitute actual testing of physical hardware. For any type of performance testing, please test SMP-FT using real hardware.

Requirements:

  • pESXi host running either ESXi 5.5 or 6.0
  • vCenter Server 6.0
  • 2 x Nested ESXi VMs running ESXi 6.0 (vHW9+)
  • Shared storage for the Nested ESXi VMs

Instructions:

Step 1 - Created a Nested ESXi VM using guestOS type "ESXi 5.5/6.0 or later". You will need at least 2 vCPU or greater, 4GB of memory or greater for the installation of ESXi and most importantly, a VMXNET3 network adapter. The reason a VMXNET3 adapter is required is that SMP-FT has a requirement for 10Gbit network connection and the VMXNET3 driver can simulate a 10Gbit connection for a Nested ESXi VM. For further instructions on creating a Nested ESXi VM, please take a look at this article. If you are unable to add VMXNET3 adapter, you may need to first change the guestOS type to "Other 64-bit", add the adapter and then change the guestOS type back.

smp-ft-nested-esxi-0
Step 2 - Install ESXi 6.0 on the Nested ESXi VM and ensure you also have a vCenter Server 6.0 deployed if you have not done so already and add your Nested ESXi instances to a new vSphere Cluster which has vSphere HA enabled.

Step 3 - You will need to enable both vMotion and Fault Tolerance traffic type for the VMkernel interface that you wish to run FT traffic across.

smp-ft-nested-esxi-1
Step 4 - At this point, you can create a real or dummy VM and power it on. Once you have the powered on VM, you can now enable either UP-FT or SMP-FT by right clicking and selecting "Enable Fault Tolerance".

smp-ft-nested-esxi-2
As you can see from the screenshot above, I have successfully enabled FT on a VM with 4vCPU running inside of a Nested ESXi VM, how cool is that!? Hopefully this will help you get more familiar with the new SMP-FT feature when you are ready to give it a real spin on real hardware 🙂

Note: Intel Sandy Bridge is recommended when using SMP-FT (real physical hardware) but if you have older CPUs, you enable "Legacy FT" mode by adding the following VM Advanced Setting "vm.uselegacyft" to the VM you are enabling FT on.

Categories // ESXi, Nested Virtualization Tags // fault tolerance, nested ft, nested virtualization, smp-ft, vm.uselegacyft, vSphere 6.0

Home Labs made easier with VSAN 6.0 + USB Disks

03.04.2015 by William Lam // 23 Comments

VSAN 6.0 includes a large number of new enhancements and capabilities that I am sure many of you are excited to try out in your lab. One of the challenges with running VSAN in a home lab environment (non-Nested ESXi) is trying to find a platform that is both functional and cost effective. Some of the most popular platforms that I have seen customers use for running VSAN in their home labs are the Intel NUC and the Apple Mac Mini. Putting aside the memory constraints in these platforms, the number of internal disk slots for a disk drive is usually limited to two. This would give you just enough to meet the minimal requirement for VSAN by having at least a single SSD and MD.

If you wanted to scale up and add additional drives for either capacity purposes or testing out a new configurations, you are pretty much out of luck, right? Well, not necessary. During the development of VSAN 6.0, I came across a cool little nugget from one of the VSAN Engineers where USB-based disks could be claimed by VSAN which could be quite helpful for testing in a lab environment, especially using the hardware platforms that I mentioned earlier.

For a VSAN home lab, using cheap consumer USB-based disks which you can purchase several TB's for less than a hundred dollars or so and along with USB 3.0 connectivity is a pretty cost effective way to enhance hardware platforms like the Apple Mac Mini and Intel NUCs.

Disclaimer: This is not officially supported by VMware and should not be used in Production or evaluation of VSAN, especially when it comes to performance or expected behavior as this is now how the product works. Please use supported hardware found on the VMware VSAN HCL for official testing or evaluations.

Below are the instructions on how to enable USB-based disks to be claimable by VSAN.

Step 1 - Disable the USB Arbitrator service so that USB devices can been seen by the ESXi host by running the following two commands in the ESXi Shell:

/etc/init.d/usbarbitrator stop
chkconfig usbarbitrator off

vsan-usb-disk-1
Step 2 - Enable the following ESXi Advanced Setting (/VSAN/AllowUsbDisks) to allow USB disks to be claimed by VSAN by running the following command in the ESXi Shell:

esxcli system settings advanced set -o /VSAN/AllowUsbDisks -i 1

vsan-usb-disk-2
Step 3 - Connect your USB-based disks to your ESXi host (this can actually be done prior) and you can verify that they are seen by running the following command in the ESXi Shell:

vdq -q

vsan-usb-disk-3
Step 4 - If you are bootstrapping vCenter Server onto the VSAN Datastore, then you can create a VSAN Cluster by running "esxcli vsan cluster new" and then contribute the storage by adding the SSD device and the respective USB-based disks using the information from the previous step in the ESXi Shell:

esxcli vsan storage add -s t10.ATA_____Corsair_Force_GT________________________12136500000013420576 -d mpx.vmhba32:C0:T0:L0 -d mpx.vmhba33:C0:T0:L0 -d mpx.vmhba34:C0:T0:L0 -d mpx.vmhba40:C0:T0:L0

vsan-usb-disk-4
If we take a look a the VSAN configurations in the vSphere Web Client, we can see that we now have 4 USB-based disks contributing storage to the VSAN Disk Group. In this particular configuration, I was using my Mac Mini which has 4 x USB 3.0 devices that are connected and providing the "MD" disks and one of the internal drives that has an SSD. Ideally, you would probably want to boot ESXi from a USB device and then claim one of the internal drives along with 3 other USB devices for the most optimal configuration.

vsan-usb-disk-5
As a bonus, there is one other nugget that I discovered while testing out the USB-based disks for VSAN 6.0 which is another hidden option to support iSCSI based disks with VSAN. You will need to enable the option called /VSAN/AllowISCSIDisks using the same method as enabling USB-based disk option. This is not something I have personally tested, so YMMV but I suspect it will allow VSAN to claim an iSCSI device that has been connected to an ESXi host and allow it to contribute to a VSAN Disk Group as another way of providing additional capacity to VSAN with platforms that have restricted number of disk slots. Remember, neither of these solutions should be used beyond home labs and they are not officially supported by VMware, so do not bother trying to do anything fancy or running performance tests, you are just going to let your self down and not see the full potential of VSAN 🙂

Categories // Apple, ESXi, Home Lab, Not Supported, VSAN Tags // AllowISCSIDisks, AllowUsbDisks, apple, esxcli, mac mini, usb, Virtual SAN, VSAN, vSphere 6.0

New VOBs for creating vCenter Server alarms in vSphere 6.0

03.02.2015 by William Lam // Leave a Comment

Here are some new VOBs in vSphere 6.0 that I recently came across which can be useful on getting notified on specific events such failed login attempts in ESXi or detecting a device has gone offline in VSAN as some examples. These VOBs can be used to create vCenter Server alarms to take various actions such as a simple UI notification in the vSphere Web/C# Client to sending an email or SNMP trap regarding the event. For more information on how create vCenter Server alarms using VOBs, please take a look at these two articles here and here which also includes a comprehensive list of past vSphere VOBs in vSphere 5.5 which are still applicable in vSphere 6.0.

General vSphere 6.0 VOBs

VOB ID VOB Description
esx.audit.account.locked Remote access for an ESXi local user account has been locked temporarilly due to multiple failed login attempts.
esx.audit.account.loginfailures Multiple remote login failures detected for an ESXi local user account.
esx.audit.esxcli.host.restart Rebooting host through esxcli
esx.audit.lockdownmode.exceptions.changed List of lockdown exception users has been changed.
esx.problem.coredump.copyspace The free space available in default coredump copy location is insufficient to copy new coredumps.
esx.problem.coredump.extraction.failed.nospace The given partition has insufficient amount of free space to extract the coredump.
esx.problem.dhclient.lease.offered.error No expiry time on offered DHCP lease.
esx.problem.pageretire.selectedbutnotretired.high Number of host physical memory pages that have been selected for retirement but could not yet be retired is high.
esx.problem.swap.systemSwap.isPDL.cannot.remove System swap at path {1} was affected by the PDL of its datastore and was removed. System swap has been reconfigured.
esx.problem.swap.systemSwap.isPDL.removed.reconfig.failure System swap at path {1} was affected by the PDL of its datastore. It was removed but the subsequent reconfiguration failed.
esx.problem.vmfs.ats.incompatibility.detected Multi-extent ATS-only VMFS Volume unable to use ATS
esx.problem.vmfs.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected.
esx.problem.vmfs.spanned.lockmode.inconsistency.detected Inconsistent VMFS lockmode detected on spanned volume.
esx.problem.vmfs.spanstate.incompatibility.detected Incompatible VMFS span state detected.
esx.vFlash.VFlashResourceCapacityExtendedEvent vFlash resource capacity is extended
vprob.vmfs.heartbeat.corruptondisk VMFS Heartbeat Corruption Detected

VSAN 6.0 VOBs

VOB ID VOB Description
esx.audit.vsan.net.vnic.added Virtual SAN virtual NIC has been added.
esx.audit.vsan.net.vnic.deleted Virtual SAN network configuration has been removed.
esx.problem.vob.vsan.dom.lsefixed Virtual SAN detected and fixed a medium error on disk.
esx.problem.vob.vsan.dom.nospaceduringresync Resync encountered no space error
esx.problem.vob.vsan.lsom.disklimit2 Failed to add disk to disk group.
esx.problem.vsan.dom.init.failed.status Virtual SAN Distributed Object Manager failed to initialize
vprob.vob.vsan.pdl.offline Virtual SAN device has gone offline.

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

  • « Previous Page
  • 1
  • …
  • 118
  • 119
  • 120
  • 121
  • 122
  • …
  • 154
  • 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
  • Reddit
  • RSS
  • Twitter
  • Vimeo

Recent

  • VCF 9.1 - Configuring Harbor to use VCF Identity Broker (IDB) for External Identity Federation 08/19/2026
  • Quick Tip: The Fastest Way to Clear Partitions for ESX Reinstallation 08/15/2026
  • Quick Tip: Reducing High CPU Utilization in VCF Automation (VCFA) on AMD Zen4/Zen5 CPUs 08/12/2026
  • VCF 9.1 - Quick Tip: Optimized Workflow for Configuring Distributed Transit Gateway (DTGW) with NSX Virtual Network Appliance (VNA) 08/11/2026
  • Quick Tip: Selective ESX Host Patching in VCF 9.1 08/10/2026
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 © 2026

Loading Comments...