Yellow Bricks

by Duncan Epping

Storage

Can I have an AF-4 ReadyNode for vSAN ESA with less memory?

· · Leave a Comment

I got this question the other day, and it was around the amount of memory the AF-4 ReadyNode configuration needs to have in order for it to be supported. I can understand where the question comes from, but what most people don’t seem to understand is that there’s a set of minimal requirements, and that the ReadyNode profiles are as the KB states a “guidance”. The listed configurations are a guidance. This guidance is based on the anticipated resource consumption for a given set of VMs. Of course, this could be very different for your workload. That is why this article that describes the hardware guidance now clearly states the following:

To maintain a configuration supported by VMware Global Services (GS), all ReadyNodes certified for vSAN ESA must meet or exceed the resources of the smallest configuration (vSAN-ESA-AF-0 for vSAN HCI or vSAN-Max-XS for vSAN Max).

This not only applies to memory, but also to other components, as long as you meet the minimum specified below.

Can I have an AF-4 ReadyNode for vSAN ESA with less memory?

VCF-9 Vision for a Federated Storage View and vSAN (stretched cluster) visualizations!

· · Leave a Comment

As mentioned last week, the sessions at Explore Barcelona were not recorded. I still wanted to share with you what it is we are working on, so I decided to record and share a few demos, and some of the slides we presented. In this video, I show our vision for a Federated Storage View for both vSAN and more traditional storage systems. This federated view will not only provide insights in terms of capacity and performance capabilities, it will also provide you with a visualization of a stretched cluster configuration. This is something that I have been asking for for a while now, and it looks like this will become a reality in VCF 9 at some point. As this revolves all around visualization, I would urge you to watch the below video. And as always, if you have feedback, please leave a comment!

Unexplored Territory #004: vVols with Cody Hosterman!

· ·

Episode 004 is out! This time we talk to Cody Hosterman, Director of Product Management at Pure Storage, about Virtual Volumes aka vVols! Cody shares with us the past, present, and future of vVols. I especially enjoyed his explanations around the benefits of vVols for traditional and cloud-native workload. It is also great to hear that VMware is working with Pure Storage on designing and developing a stretched cluster capability for vVols based environments. Listen below, or via Apple, Google, Spotify etc.

What is this Catalog folder on my datastore?

· ·

A question popped up on our internal slack earlier these days, and as I didn’t find anything online for it I figured I would write a quick article. When you look at your datastore, you may find various folders. Some you will recognize like the “.vSphere-HA” folder structure, which is used by vSphere HA, others you may not recognize, like the folder called “catalog” (see screenshot below), which has folders like “shard”, “mutex”, “tidy”, and “vclock” in it. The folder “catalog”, and all folders underneath, are created automatically when you use First Class Disk’s (FCD). FCD uses the folder structure to store it’s metadata in it. So please do not remove/delete or touch these folders. If you like to know more about FCD, make sure to read Cormac’s post on it.

Oh and if wonder why you are using FCD in the first place, it is often used for Kubernetes “persistent volumes”. So if you are using Tanzu/Kubernetes and have persistent volumes, chances are you are using FCD, which would result in those folders on your datastore. Nothing to worry about. 🙂

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.