Yellow Bricks

by Duncan Epping

#116 – A VMware Cloud Foundation constructs primer featuring Gary Blake!

· · Leave a Comment

I sometimes get confused when people talk about VMware Cloud Foundation (VCF) Fleets, Instances, and Domains! So I decided to invite Gary Blake to the show to explain to us all the various constructs, how they relate to each other, and what you should take into consideration when you are designing a VCF-based infrastructure! You can find the links to some of the discussed articles and documents below. As always, you can listen to the episode on Spotify (https://bit.ly/4tBCNFw), Apple (https://bit.ly/3Q5DU1V), via the embedded audio player below, or simply watch the episode on youtube!

vSphere HA setting Performance degradation VMs tolerate

· · Leave a Comment

There was a question this week internally and I really had to start digging, as I have not looked at this in a loooong time. What does “Performance degradation VMs tolerate” do? And does this feature require admission control to be enabled or not?

vSphere HA setting Performance degradation VMs tolerate

I had to test this, as I barely ever play around with the HA settings these days. But, let’s first describe what this feature is for. I think the UI explains it fairly decently, but here’s my explanation from the vSphere Clustering Deep Dive:

This feature allows you to specify the performance degradation you are willing to incur if a failure happens. It is set to 100% by default, but it is our recommendation to consider changed the value. You can for instance change this to 25% or 50.

Now, the requirement for this feature to work is to have DRS enables, but Admission Control does not need to be enabled! A lot of people are under the impression that it requires Admission Control in order to take “an X number of failures” into account, but it does not. It actually does not use what is specified for Admission Control. It takes a single failure into account when it comes to this feature, and then uses DRS to do the calculations if powered on VMs will get the same amount of resources allocated after a failure. If the answer is no, or performance degradation is higher than the percentage specified, a warning is triggered. You will still be able to power on new VMs, but the warning will not go away unless the resource usage changes, or you add more resources to the cluster.

#115 – GPU resource management for AI workloads with Frank Denneman!

· · Leave a Comment

Recently, Frank published a series of blog posts on GPU resource management. I invited Frank to the show to explain why GPU resource management is different than CPU and memory management in vSphere. Frank goes over all the intricate details, and as always, dives deep into the various constructs involved. I highly recommend reading the articles which are part of the following series, and make sure to also check the tool Frank developed, as this helps visualizing the challenges you may face today, or potentially in the future!

You can listen to the episode on Spotify (bit.ly/4th0Jhs), Apple (bit.ly/47wcGHH), or via the below embedded player, and I also posted it on Youtube with video!

#114 – vSAN Storage Clusters with Kalyan Krishnaswamy!

· · Leave a Comment

Recently there was a ⁠big announcement⁠ about the adoption of vSAN Storage Clusters by Audi. All the reasons for me to invite Kalyan back to the show. During this episode, Kalyan not only discusses what was announced specifically with Audi, but also goes over some of the recently introduced functionality like vSAN traffic separation, vSphere only clusters support for stretched with vSAN Storage Clusters, and much more!

Some of the discussed papers and blogs:

You can listen to the episode on Spotify (bit.ly/4lBkM7K), Apple (apple.co/4lzCjwX), the embedded player below, or simply watch the youtube version!

vSAN ESA Witness memory and CPU resources?

· · Leave a Comment

Not sure when this happened, but somehow the resource requirements for the vSAN Witness VM disappeared. Someone asked me last week how much memory is allocated to a VM, and how many vCPUs. Now, of course, this depends on the profile you select as the Witness VM has an M, L, and XL profile. The profile you select is determined by the number of VMs you will be provisioning, yes it is smart to take a growth factor into account. Now, when you deploy the VM, it doesn’t give a hint either, but you can figure out the size by simply looking at the OVF descriptor file. So this is what I got from the vSAN ESA Witness OVF:

  • vSAN ESA Witness XL – 8 vCPUs – 64 GB memory
  • vSAN ESA Witness L – 4 vCPUs – 32 GB memory
  • vSAN ESA Witness M – 4 vCPUs – 16 GB memory

And for those who were wondering, with vSAN OSA the requirements are:

  • vSAN OSA Witness XL – 6 vCPUs – 32 GB memory
  • vSAN OSA Witness L – 2 vCPUs – 32 GB memory
  • vSAN OSA Witness Normal – 2 vCPUs – 16 GB memory
  • vSAN OSA Witness Tiny – 2 vCPUs – 8 GB memory

I hope that helps, and also please do note… if you read this article a few years from now, things may have changed!