Yellow Bricks

by Duncan Epping

Compute only HCI Mesh with vSAN 7.0 U2

· · 13 Comments

I guess that title explains it all, starting with vSAN 7.0 U2, we now also support connecting a compute-only cluster with a vSAN cluster. Meaning that if you have a vSphere cluster that does not have vSAN enabled, you can now mount a remote vSAN Datastore to it and leverage all the capabilities it provides!

I am sure seeing this new capability will make many of you happy, as we had many customers asking for this when we launched HCI Mesh with vSAN 7.0 U1. The great thing is that there’s no need for a vSAN license on the compute-only cluster, even though we load up the vSAN Client on the Client Cluster. No, we are not using NFS, but we are using the vSAN proprietary protocol for this. Another thing that may be useful to know is that we doubled the number of hosts that can be connected to a single datastore, this has gone from 64 to 128!

Last but not least, we have also extended the Policy Based Management Framework to allow for customers to specify which data services should be enabled on a datastore level. So if you select a policy, the vSAN datastores that will be presented, should not only be able to provide the RAID configuration specified, but should also have the data services enabled you require. Those data services would be: Deduplication and Compression, Compression, and/or Encryption, as shown in screenshot of the new policy capability below.

As mentioned, the feature itself is pretty straightforward and very easy to use. There are some things to take into consideration, of course, I wrote those down here. If you want to see it in action, make sure to check the demo below.

vSAN 7.0 U2 Skyline Health History

· · Leave a Comment

I have already discussed this briefly during my 7.0 U2 video presentation, which can be found here, but I also wanted to share the demo I recorded with you, and provide some additional details. Over the past years, one of the most requested features for Skyline Health, or Health Check as it used to be called, was the ability to go back in time to see what has happened between certain dates. This functionality was demonstrated at VMworld, and a few VMUGs the past year, and now finally made it into the release with vSAN 7.0 U2.

The “health history” feature simply provides a toggle that enables you to go back in time. When you tick the toggle, you can specify a date range. Note that the range can be anywhere between the current date, and 30 days back. The health check data is stored, for 30 days, in the vCenter Server database. This is important to know because if you feel that there’s no need to store the data, you can disable the feature under vSAN Services in the Configuration tab. When you disable the feature the data is deleted from the vCenter Server database. Now if you flip the toggle, set a date range, and look at the different checks you should see green checks. If a check is not green, but rather red or orange you can click the check.

When clicking on the red square, you will see which check failed, and when exactly it failed. The number in the square or circle refers to the number of checks that were run and resulted in the same state. In other words, 37 red, 45 green, 54 red checks etc. When you click on it, you will see the below.

Hopefully, this will then allow you, during troubleshooting, to correlate particular failures or configuration changes, to the issue that bubbled up in the health check. I feel that having the date/time is already very useful, as it will allow you to focus on a more specific date/time range while reading logs or going through the events section.

Anyway, if you would like to see the feature in action, check out the demo below.

Introducing VMware vSAN 7.0 Update 2 (video)

· · 3 Comments

As you may have seen, today VMware announced the release of VMware vSAN 7.0 Update 2 (and vSphere 7.0 U2 as well of course). I was planning on doing a post on the 7.0 U2 release, but then I figured that I would try to record a video discussing most of the new features and enhancements introduced. Note, I do not cover the full release, I picked the features which I felt deserved some attention. I uploaded the video to my Youtube Channel, make sure to visit it and subscribe, as I will be releasing demos on various features in the upcoming weeks with some more detail where needed. Hope you enjoy it, and again, make sure to like the video and subscribe to the channel!

Can I vMotion a VM while IO Insight is tracing it?

· · 2 Comments

Today during the Polish VMUG we had a great question, basically, the question was if you can vMotion a VM while vSAN IO Insight is tracing it. I did not know the answer as I had never tried it, so I had to test and validate it in the lab. While testing it became obvious that IO Insight and vMotion are not a supported combination today. Or better said, when you vMotion a VM which has IO Insight enabled and the VM is being traced, then the tracing will stop and you will not be able to inspect the results. When you click on view results you will see the error suggesting that the “monitored VMs might be deleted” as shown below.

For now, if you are tracing a VM for an extended period of time, make sure to override the DRS automation level for that VM so that DRS does not interfere with the tracing. (You can do this on a per VM basis.) I would also recommend informing other administrators to not manually migrate the VM temporarily to avoid the situation where the trace is stopped.  You may wonder why this is the case, well it is pretty simple, tracing happens on a host level. We start a user world on the host where the VM is running to trace the IO. If you move the VM, the user world doesn’t know what has happened to the VM unfortunately. For now, who knows if this is something that may change over time… Either way, I would always recommend not migrating VMs while tracing, as that also impacts the data.

Hope that helps, and thank Tomasz for the great question!

What is this Catalog folder on my datastore?

· · Leave a Comment

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. 🙂