Read-Write-Many Persistent Volumes with vSAN 7 File Services

A few weeks back, just after the vSphere 7.0 launch event, I wrote an article about Native File Services in vSAN 7.0. I had a few questions asking why we decided on NFS support in this initial release, and not something like SMB or some other protocol. The reason is quite straight-forward. We are positioning vSAN as a platform for both traditional virtual machine workloads and newer containerized workloads. We chose NFS to address a storage requirement in Kubernetes, namely a way to share Persistent Volumes between Pods. To date, the vSphere CSI driver only provisioned block based Persistent Volumes…

Getting started with VCF 4.0 Part 3 – vSphere with Kubernetes in a Workload Domain

At this point, we have a fully configured workload domain which includes an NSX-T Edge deployment. Check here for the previous VCF 4.0 deployment steps. We are now ready to go ahead and deploy vSphere with Kubernetes, formerly known as Project Pacific. Via SDDC Manager in VMware Cloud Foundation 4.0, we ensure that an NSX-T Edge is available, and we also ensure that the the Workload Domain is sufficiently licensed to enable vSphere with Kubernetes. Disclaimer: “To be clear, this post is based on a pre-GA version of the VMware Cloud Foundation 4.0. While the assumption is that not much…

Getting started with VCF 4.0 Part 2 – Commission hosts, Create Workload Domain, Deploy NSX-T Edge

Now that a VCF 4.0 Management Domain has been deployed, we can move onto creating our very first VCF 4.0 Virtual Infrastructure Workload Domain (VI WLD). We will require a VI WLD with an NSX-T Edge cluster before we can deploy Kubernetes on vSphere (formerly known as Project Pacific). Not too much has changed in the WLD creation workflow since version 3.9. We still have to commission ESXi hosts before we can create the WLD. But something different to previous versions of VCF is that today in VCF 4.0 we can automatically provision NSX-T Edge clusters from SDDC Manager to…

Getting started with VMware Cloud Foundation (VCF) 4.0

On March 10th, VMware announced a range of new updated products and features. One of these was VMware Cloud Foundation (VCF) version 4.0. In the following series of blogs, I am going to show you the steps to deploy VCF 4.0. We will begin with the deployment of a Management Domain. Once this is complete, we will commission some additional hosts and build our first workload domain (WLD). After that, we will deploy the latest version of NSX-T Edge Cluster to our Workload Domain. The great news here is that this part has now been automated in VCF 4.0. Finally,…

Track vSAN Memory Consumption in vSAN 7

One of the most common requests in relation to vSAN performance is how much CPU and memory does vSAN actually consume on an ESXi host, i.e. what is the overhead of running vSAN. Through the vSAN Performance Service, we have been able to show both host and vSAN CPU usage for some time. However, up to now, we have only been able to show host memory usage, and not overhead attributed to vSAN. It has also been extremely difficult to determine how much memory vSAN required.  Way back in 2014, with the first vSAN version 5.5 release, I wrote this…

Native File Services for vSAN 7

On March 10th 2020, we saw a plethora of VMware announcements around vSphere 7.0, vSAN 7.0, VMware Cloud Foundation 4.0 and of course the Tanzu portfolio. The majority of these announcements tie in very deeply with the overall VMware company vision which is any application on any cloud on any device. Those applications have traditionally been virtualized applications. Now we are turning our attention to newer, modern applications which are predominantly container based, and predominantly run on Kubernetes. Our aim is to build a platform which can build, run, manage, connect and protect both traditional virtualized applications and modern containerized…

Getting started with VCF Part 14 – Connecting vRA to NSX-T WLD (alternate method)

In my most recent VMware Cloud Foundation post (part 13), I highlighted the fact that if you used NSX-T as the networking platform for your workload domain (WLD), you could not attach vRealize Automation (vRA) to such a WLD via SDDC Manager. In that previous post, I showed how to manually deploy the vRA proxy agents on the Proxy VMs. These Proxy VMs were already deployed via SDDC Manager as part of the overall vRA deployment through SDDC Manager, but the agents were not installed at this point. If NSX-V was used as the networking platform for the WLD, then…