VMware vSphere with Tanzu VM service on DELL EMC PowerStore vVOLs

With the release of vCenter 7.0 U2a, VMware has introduced VM Service. VM Service runs on top of vSphere with Tanzu and allows developers to deploy Virtual Machines using kubectl declarative object configuration while simultaneously allowing the IT administrator to govern resource consumption and service availability.

This blog post will be focusing on the new vSphere with Tanzu VM Service feature and what benefits do we get from running it on PowerStore VVOLs

VM Service allows DevOps engineers to deploy and run Virtual Machines in a shared Kubernetes environment. Virtual Machines are deployed using kubectl, like containers, directly to Supervisor Namespaces.

How does it work?

VM Service is made up of two components, a vSphere side component and a Kubernetes side component.

The vSphere side is built right into vCenter, it allows you to manage VM Images (Content Libraries) and VM Classes (VM sizing), the Kubernetes side is called VM Operator which creates and services the Kubernetes Custom Resources (CRs/CRDs), which we’ll get into later, and tells K8s how to talk to vSphere.

One of the new features that was added in vSphere 7.0 is the ability to provision Virtual Volumes (vVols) to back Kubernetes Persistent Volumes (PVs) via the updated version of the vSphere Container Storage Interface (CSI) driver.

PowerStore vVols leverage Storage Policy Based Management (SPBM) to ensure VMs have the appropriate storage capabilities through their entire life cycle. VM storage policies can be optionally created after the storage provider is registered. These policies are used to determine the desired storage capabilities when a VM is being provisioned.

vVol datatores can be added to the vSphere Kubernetes namespace as SPBM policies by clicking on the edit storage button

Like pods and persistent volumes provisioning, these Storage Policy Based Management that represent storage classes at the Kubernetes level, can be used for virtual machines deployment using the VM service.

The vSphere side of the VM Service is very straight forward, it is created as part of your vSphere with Tanzu namespaces once you enable the service in the new Workload Management “Services”

Inside the VM Service, you’ll find where you can manage the components, namely the VM Images (Content Libraries) and VM Classes (t-shirt sizes).

From Kubernetes perspective, we have the new VM Operator, The VM Operator creates Kubernetes CRDs for a few different types that allows K8s users to discover and define the resources they need from the Operator, the most important types they would be interested in are VirtualMachine, VirtualMachineImage, VirtualMachineClasses and VirtualMachineServices.

Virtual Machines in vSphere with Tanzu Namespaces the templates have to be deployed from a content library. VMware provides supported Images in their Marketplace. So we can upload their to the vCenter content library

As I’ve mentioned before, in vSphere with Tanzu, VMware SPBM policies represent K8s storage classes which can be used to create persistent volumes using the VMware CNS.

To create virtual machines using the Kubernetes API, we use, of course, yaml files –

As for the storage class name, we specify the VVOL SPBM policy, which automatically creates virtual volumes for each virtual machine file on the PowerStore array.

To deploy Virtual Machines, it required to know in which networking mode the Supervisor Cluster is running. VM Service supports both modes, NSX-T and Distributed Portgroups. When using NSX-T, VM Operator will automatically create the required network segments and attach virtual machine interfaces. In that case, you just set the networkType to nsx-t.

We create the VM by running the kubectl apply command and specifying the YAML files, within a few seconds, we can find the new VM up and running in the vSphere web client.

If we navigate to PowerStore manager and click on the virtual machines tab, we can see that PowerStore automatically detected the newly created virtual machines that we’ve just deploying using the new Tanzu VM service.

We can see useful information about the VM such as the managing ESXi host, the guest OS, the capacity and the protection policy, and it doesn’t stop there, PowerStore collects and displays both history and live performance metrics about the virtual machine, allowing the storage admin to get full visibility of the virtual machines running on the PowerStore storage array.

The type of vVol provisioned depends on the type of data that is being stored:

• Config: Stores standard VM configuration data such as .vmx files, logs, and NVRAM

• Data vvols: Stores data such as VMDKs, snapshots, full clones, and fast clones

• Swap: Stores a copy of the VM memory pages when the VM is powered on. Swap vVols are automatically created and deleted when VMs are powered on and off.

In addition to the compute performance, we provide storage performance metrics showing the total IOPS, bandwidth, latency and IO size of the VM, and if that’s not enough, because each vmdk file is a virtual volume at the array level, we have a more granular view of the performance of each and every disk of the VM.

If we navigate to a specific VM and select one of its disks, we can get live performance metrics of that disk, allowing the storage administrator go get full visibility of the workloads running in his data center, no matter if these are regular virtual machines, virtual machines managed by the VM service, Supervisor Kubernetes pods, and Tanzu guest cluster workloads, all, from a single pane of glass.