A short video to demonstrate how vSAN File Service file shares, which are used to back dynamically created Kubernetes read-write-many persistent volumes (PVs) have an implicit hard quota associated with them. Read-Write-Many (RXW) PVs are volumes which can be shared between multiple Kubernetes Pods. For more details about this feature, please check out this earlier blog post.
Last week I looked at how quotas were implicit on Kubernetes RWX Persistent Volumes which were instantiated on vSAN File Service file shares. This got me thinking about another feature of Kubernetes Persistent Volumes – how could some of the other parameters associated with file shares be controlled? In particular, I wanted to control which networks could access a volume, what access permissions were allowed from that network and whether we could squash root privileges when a root user accesses a volume? All of these options are configurable from the vSphere client and are very visible when creating file shares…
Earlier this week, I participated in a customer call around vSAN File Service and Kubernetes Persistent Volumes. I have highlighted the dynamic Read-Write-Many Persistent Volume feature of our vSphere CSI driver in conjunction with vSAN File Service before. Read-Write-Many (RWX) volumes are volumes that can be accessed/shared by multiple containers. During the discussion, one question came up in relation to quota, and if it can be applied to Persistent Volumes which are backed by file shares from vSAN File Service, which is the purpose of this post. Now, for those of you who are familiar with vSAN File Service, you…
Last week, I wrote an article which described how to use a combination of vSAN Availability Rules with Tag Based Placement Rules in vSAN Storage Policies to select one specific vSAN datastore for object placement when many vSAN datastores might appear as compatible candidates. I create this short 3m30s video to show how to do this in practice.
I know that there has been a lot of content already written in relation to the latest 7.0U2 release of vSAN. My good pal Duncan has done a considerable amount on work to highlight the new features, and has an excellent set of YouTube videos that you can review at your convenience. However, I thought I would create a bite-sized overview of some of the big ticket items that are in the vSAN 7.0U2 release, as many of my readers have asked me about some of these features in the past. I’m not covering all of the features, of which…
In this short video, I will demonstrate a new feature of vSphere with Tanzu, namely the vSAN Data Persistence platform. In this demo, we will show how easy it is to deploy a Supervisor Service using vSAN DPp. The service that we are deploying is MinIO, a provider of on-premises S3 Object Stores. We will see how to enable the Service, and then how to provision a dedicated S3 Object Store to a particular Namespace with vSphere with Tanzu. This means that a developer or a team of developers using a particular namespace can have their own dedicated S3 Object…
This is something I noticed on my own lab after applying the most recent disk format (version 13) to my vSAN 7.0U1 environment. I already described the new Capacity Management features in vSAN 7.0U1 in a previous post. One of these features in the new capacity reserve which dramatically lowers the slack space requirements, and which are now controlled by two new parameters, Operations Reserve and Host Rebuild Reserve. Slack space is the term we used for the amount of space that needed to be set aside for operations such as the reconfiguration of objects after a policy change, and…