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 was recently working in an environment where my vCenter server was managing two vSAN clusters, each with its own datastore. I wanted to be able to choose which datastore to provision to via storage policy, but came across some unexpected behaviour. When I configured my vSAN Rule and my Tag Rule, it seems that both datastores would appear as compliant to the policy. I found out the reason, and decided to write it up as I had never known this was how policies AND and OR rules behaved until now. Setting up Tags I created a Tags Category called…
I’ve recently been looking at the vSphere Velero Plugin, and how the latest version of the plugin enables administrators to backup and restore vSphere with Tanzu Supervisor cluster objects as well as Tanzu Kubernetes “guest” cluster objects. This plugin utilizes vSphere snapshot technology, so that a Kubernetes Persistent Volume (PV) backed by a First Class Disk (FCD) in vSphere can be snapshot, and the snapshot is then moved by a Data Manager appliance to an S3 object store bucket. Once the data movement operation has completed, the snapshot is removed from the PV/FCD. During the testing of this new functionality,…
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…