• Skip to primary navigation
  • Skip to main content
  • Skip to primary sidebar

Yellow Bricks

by Duncan Epping

  • Home
  • Unexplored Territory Podcast
  • HA Deepdive
  • ESXTOP
  • Stickers/Shirts
  • Privacy Policy
  • About
  • Show Search
Hide Search

vSAN

Scaling out your vSAN File Services Cluster

Duncan Epping · Apr 10, 2020 ·

This week I have been testing with vSAN File Services and one of the procedures I wanted to run through was scaling out my vSAN File Services cluster. In my case, I have a cluster of 5 hosts and what I want to do is add a host to my vSAN cluster, expand the vSAN Datastore and also grow my vSAN File Services cluster.

First of all, when you add a host into the cluster you need to make sure it is in maintenance mode. If if is not in maintenance mode then vSAN FS will instantly try to clone a vSAN File Services agent VM (FS VM) on to it and that process will fail as there’s no disk group yet. So make sure to place the host into maintenance mode before adding it to the cluster.

After you added it to the cluster, you have to create the disk group first. Claim all the disks that need to be part of the disk group and create the disk group. When you have done that you can take the host out of maintenance mode. Now the FS VM will be cloned and powered on. However, one thing you will need to do is expand the IP Pool for the vSAN FS Protocol Stack container. You can do this as follows:

  • Go to your cluster
  • Click on vSAN / Services
  • Go to File Service and click Edit on the right
  • Go to the IP Pool page by clicking Next twice
  • Add that additional IP address and DNS Name
  • Click Next / Finish

Now a new Protocol Stack Container can be instantiated in that new FS VM and your vSAN File Services cluster has been scaled out properly. I created a simple demo showing you what the process looks like, make sure to check it out below!

ESXTOP in vSphere 7

Duncan Epping · Apr 2, 2020 ·

I was playing around with Scalable Shares and then noticed some enhancements in esxtop which I didn’t realize were there. I figured I would list the changes I spotted so people are aware of what was added to esxtop in vSphere 7.0. Although it isn’t a huge amount, it is still very valuable to know!

  • RDMA Device “display” is added, so a fully new category for those running RDMA!
    • This, of course, has fields like “Megabits Tx/s”, “% Packets Dropped” etc.
  • CPU Display now has the ability to disable the PCPU usage info at the top by typing “f” followed by “k”
  • vSAN Display now provides UNMAP stats (E, F) additionally

What is also new is that you can now suppress the server physical CPU stats when you type “esxtop -u”, this could be useful when dumping your info into a .csv file. I just added the new details to my ESXTOP page as well, for those who use that as a reference. If there’s more I stumble into then I will report it.

Creating a vSAN 7.0 Stretched Cluster

Duncan Epping · Mar 31, 2020 ·

A while ago I wrote this article and created this demo showing the creation of a vSAN Stretched Cluster. I bumped into the article/video today when I was looking for something and figured that it is time to recreate the vSAN Stretched Cluster demo. I recorded it today, using vSphere / vSAN 7, and just wanted to share it with you here. Hope you enjoy it.

Introducing vSAN File Services as part of vSAN 7.0

Duncan Epping · Mar 17, 2020 ·

There was a great article by Cormac talking about vSAN File Services published last week. I had some articles planned, but hadn’t started yet, so when I saw the article I figured I would do something different. No point in rehashing what Cormac has already shared right. I figured I would shoot another demo, and do a brief write-up so people know what vSAN File Services is all about. In vSAN/vSphere 7.0 there’s now a new feature, and this is vSAN File Service. vSAN File Services can simply be enabled on a cluster level and provides you NFS 3 and 4.1 capabilities. The great thing about the solution is that you can create file shares and associate policies with the file shares. In other words, you can have a file share with RAID-1, RAID-5, or maybe even striping or stretched across locations when that is supported.

When you enable File Service, vSAN will deploy a number of “agent VMs” and these VMs/appliances are fully managed by vSAN. These agent VMs run Photon OS and have the file service capabilities enabled through docker/container technology. After these File Service Agent VMs have been deployed, the docker container instances have been instantiated and configured, vSAN File Service will be up and running and available for use. Next, you could simply create a file share and start consuming it. But before I reveal everything, let’s just head over to the demo below. I hope you enjoy it!

Can I still provision VMs when a vSAN Stretched Cluster site has failed? Part II

Duncan Epping · Dec 18, 2019 ·

3 years ago I wrote the following post: Can I still provision VMs when a VSAN Stretched Cluster site has failed? Last week I received a question on this subject, and although officially I am not supposed to work on vSAN in the upcoming three months I figured I could test this in the evening easily within 30 minutes. The question was simple, in my blog I described the failure of the Witness Host, what if a single host fails in one of the two “data” fault domains? What if I want to create a snapshot for instance, will this still work?

So here’s what I tested:

  • vSAN Stretched Cluster
  • 4+4+1 configuration
    • Meaning, 4 hosts in each “data site” and a witness host, for a total of 8 hosts in my vSAN cluster
  • Create a VM with cross-site protection and RAID-5 within the location

So I first failed a host in one of the two data sites. When I fail the host, the following is what happens when I create a VM with RAID-1 across sites and RAID-5 within a site:

  • Without “Force Provisioning” enabled the creation of the VM fails
  • When “Force Provisioning” is enabled the creation of the VM succeeds, the VM is created with a RAID-0 within 1 location

Okay, so this sounds similar to the originally described scenario, in my 2016 blog post, where I failed the witness. vSAN will create a RAID-0 configuration for the VM. When the host returns for duty the RAID-1 across locations and RAID-5 within each location is then automatically created. On top of that, you can snapshot VMs in this scenario, the snapshots will also be created as RAID-0. One thing to mind is that I would recommend removing “force provisioning” from the policy after the failure has been resolved! Below is a screenshot of the component layout of the scenario by the way.

I also retried the witness host down scenario, and in that case, you do not need to use the “force provisioning” option. One more thing to note. The above will only happen when you create a RAID configuration which is impossible to create as a result of the failure. If 1 host fails in a 4+4+1 stretched cluster you would like to create a RAID-1 across sites and a RAID-1 within sites then the VM would be created with the requested RAID configuration, which is demonstrated in the screenshot below.

  • « Go to Previous Page
  • Page 1
  • Interim pages omitted …
  • Page 20
  • Page 21
  • Page 22
  • Page 23
  • Page 24
  • Interim pages omitted …
  • Page 71
  • Go to Next Page »

Primary Sidebar

About the Author

Duncan Epping is a Chief Technologist and Distinguished Engineering Architect at Broadcom. Besides writing on Yellow-Bricks, Duncan is the co-author of the vSAN Deep Dive and the vSphere Clustering Deep Dive book series. Duncan is also the host of the Unexplored Territory Podcast.

Follow Us

  • X
  • Spotify
  • RSS Feed
  • LinkedIn

Recommended Book(s)

Also visit!

For the Dutch-speaking audience, make sure to visit RunNerd.nl to follow my running adventure, read shoe/gear/race reviews, and more!

Do you like Hardcore-Punk music? Follow my Spotify Playlist!

Do you like 80s music? I got you covered!

Copyright Yellow-Bricks.com © 2026 ยท Log in