Yellow Bricks

by Duncan Epping

Storage

What’s new for vSAN 7.0 U1!?

· ·

Every 6-9 months VMware has been pushing out a new feature release of vSAN. After vSphere and vSAN 7.0, which introduced vSphere Lifecycle Manager and vSAN File Services, it is now time to share with you what is new for vSAN 7.0 U1. Again it is a feature-packed release, with many “smaller enhancements, but also the introduction of some bigger functionality. Let’s just list the key features that have just been announced, and then discuss each of these individually. You better sit down, as this is going to be a long post. Oh, and note, this is an announcement, not the actual availability of vSAN 7.0 U1, for that you will have to wait some time.

  • vSAN HCI Mesh
  • vSAN Data Persistence Platform
  • vSAN Direct Configuration
  • vSAN File Services – SMB support
  • vSAN File Services – Performance enhancements
  • vSAN File Services – Scalability enhancements
  • vSAN Shared Witness
  • Compression-only
  • Data-in-transit encryption
  • Secure wipe
  • vSAN IO Insight
  • Effective capacity enhancements
  • Enhanced availability during maintenance mode
  • Faster host restarts
  • Enhanced pre-check for vSAN maintenance mode
  • Ability to override default gateway through the UI
  • vLCM support for Lenovo

[Read more…] about What’s new for vSAN 7.0 U1!?

Host in vSAN cluster with 0 components while other hosts are almost full?

· ·

Internally someone just bumped into an issue where a single host in a cluster wasn’t storing any of the created vSAN Components / Objects. It was to the point where every single host in the cluster was close to the maximum of 9000 components, but that one host had 0 components. After some quick back and forth the following message stood out in the UI:

vSAN node decommission state

What does this mean? Well basically it means that from a vSAN stance this host is in maintenance mode. For whatever reason, the host itself from a hypervisor stance was not in maintenance mode, which means that the two were not in sync. This can simply be resolved by SSH’ing into the respective host and running the following command:

localcli vsan maintenancemode cancel

One thing to consider of course is to trigger a rebalance of the cluster after taking the host out of the decommissioned state when the environment is 6.7 U2 or lower, as that would result in a more equally balanced environment. Starting with  6.7 U3 this process is initiated automatically, when configured. There is a KB that describes how to trigger, and/or configure, to be found here.

VCG Notification demo and Changing the Default vSAN Policy Demo

· ·

I created two youtube video last week which I just wanted to share with everyone. In these demo’s I am showing the new VCG Notification option. The VCG Notification option is very useful for customers who want to be notified via email when a change to a component of a ready node configuration has occurred. This could be a change in support, change of driver / firmware etc.

Another demo that I recorded was around how to change the default policy for a vSAN Cluster. This seems to be an option that many folks haven’t been able to find in the UI. It is pretty straight forward, hence I am sharing it here.

 

Running ESXi in “Degraded Mode”, what does that mean?

· ·

I received a question today, and I didn’t have the answer so I reached out to one of the developers.  This person found this line in the ESXi documentation where it states the following, and the question was what does running ESXi in degrade mode actually means, or what is the impact?

If a local disk cannot be found, then ESXi 7.0 operates in degraded mode where certain functionality is disabled and the /scratch partition is on the RAM disk, linked to /tmp. You can reconfigure /scratch to use a separate disk or LUN. For best performance and memory optimization, do not run ESXi in degraded mode.

In other words “degrade mode” is a situation where you are running ESXi with a boot disk configuration which is undesired. In this case, the boot disk configuration (size, etc) results in the fact that /scratch is not stored on persistent media, but rather in RAM, which means that state is lost during a reboot. This could lead to various problems, hence it called degraded mode or state. Note that although you are now running in “degraded” mode, it could easily prevent you from upgrading potentially in the future.

So how do you resolve this problem? Follow the recommendations VMware provides for the ESXi configuration:

  • An 8 GB USB or SD and an additional 32 GB local disk. The ESXi boot partitions reside on the USB or SD and the ESX-OSData volume resides on the local disk.
  • A local disk with a minimum of 32 GB. The disk contains the boot partitions and ESX-OSData volume.
  • A local disk of 142 GB or larger. The disk contains the boot partitions, ESX-OSData volume, and VMFS datastore.

Although not a requirement, I would urge to read and follow the next sections from the documentation:

  • Although an 8 GB USB or SD device is sufficient for a minimal installation, you should use a larger device. The additional space is used for an expanded core dump file and the extra flash cells of a high-quality USB flash drive can prolong the life of the boot media. Use a 32 GB or larger high-quality USB flash drive.
  • If you install ESXi on M.2 or other non-USB low-end flash media, delete the VMFS datastore on the device immediately after installation.

If you want to mitigate the situation after upgrading to ESXi 7.0 you can add a new local disk and enable “autoPartition=TRUE” and reboot. At reboot, the disk will be partitioned and populated for usage. The use of this advanced setting, and others which relate to ESXi 7.0, are described in this KB article here.

For those wondering, “ESXi-OSData” is the partition where we now store the content of what was previously stored in “scratch”, “core”, and “locker”. Niels wrote a deep-dive on the vSphere blog here, go check that out.

Inspecting vSAN File Services share objects

· ·

Today I was looking at vSAN File Services a bit more and I had some challenges figuring out the details on the objects associated with a File Share. Somehow I had never noticed this, but fortunately, Cormac pointed it out. In the Virtual Objects section of the UI you have the ability to filter, and it now includes the option to filter for objects associated to File Shares and to Persistent Volumes for containers as well. If you click on the different categories in the top right you will only see those specific objects, which is what the screenshot below points out.

Something really simple, but useful to know. I created a quick youtube video going over it for those who prefer to see it “in action”. Note that at the end of the demo I also show how you can inspect the object using RVC, although it is not a tool I would recommend for most users, it is interesting to see that RVC does identify the object as “VDFS”.