vSphere with Tanzu offers a VM Service functionality that enables DevOps engineers to deploy and run VMs, in addition to containers, in a common, shared Kubernetes environment. You can use the VM Service to manage the lifecycle of virtual machines in a vSphere Namespace. VM Service manages stand-alone VMs and VMs that make up Tanzu Kubernetes clusters.
Generally, your business needs and goals dictate your decision to run workloads in a VM rather than in a container. For information about when to run a VM, see Using Virtual Machines in vSphere with Tanzu.
Concepts of VM Service
To describe the state of a VM to be deployed in a vSphere Namespace, you use such parameters as a VM class, a VM image, and a storage class. The VM Service then brings together these specifications to create stand-alone VMs or VMs that support Tanzu Kubernetes clusters.
- VM Service
-
The VM Service is a component of
vSphere with Tanzu that provides a declarative, Kubernetes-style API for management of VMs and associated vSphere resources. The VM Service enables the vSphere administrators to deliver resources and provide templates, such as VM classes and VM images, to Kubernetes. DevOps engineers can use these resources to describe the desired state of a VM. After the DevOps engineers specify the VM state, the VM Service converts the desired state in to a realized state against backing infrastructure resources.
A VM created through the VM Service can be managed only from the Kubernetes namespace with the kubectl commands. vSphere administrators cannot manage the VM from the vSphere Client, but can display its details and monitor resources it uses. For information, see Monitor Virtual Machines Available in vSphere with Tanzu.
- VM Class
-
The VM class is a VM specification that can be used to request a set of resources for a VM. The VM class is controlled and managed by a vSphere administrator, and defines such parameters as the number of virtual CPUs, memory capacity, and reservation settings. The defined parameters are backed and guaranteed by the underlying infrastructure resources of a Supervisor Cluster.
A vSphere administrator can create custom VM classes.
In addition, Workload Management offers several default VM classes. Generally, each default class type comes in two editions: guaranteed and best effort. A guaranteed edition fully reserves resources that a VM specification requests. A best effort class edition does not and allows resources to be overcommitted. Typically, a guaranteed type is used in a production environment.
Examples of default VM classes include the following.
Class CPU Memory (GB) Reserved CPU and Memory guaranteed-large
4 16 Yes best-effort-large
4 16 No guaranteed-small
2 4 Yes best-effort-small
2 4 No The vSphere administrator can assign any number of existing VM classes to make them available to DevOps engineers within a specific namespace.
The VM class provides a simplified experience for the DevOps engineers. The DevOps don't need to understand the full configuration of each VM that they plan to create. Instead, they can select a VM class from available options, and the VM Service manages the VM configuration.
On the Kubernetes side, the VM classes appear as VirtualMachineClass and VirtualMachineClassBinding resources.
- VM Image
-
A VM image is a template that contains a software configuration, including an operating system, applications, and data.
When DevOps engineers create VMs, they can select images from the content library associated with the namespace. To the DevOps, the images are exposed as VirtualMachineImage objects.
VM Service supports a limited number of VM images and guest OSes. Compatible VM images appear on VMware Marketplace as OVFs. Make sure to use only those VM images that are supported by VM Service. To find compatible images, search for VM Service image on the VMware Cloud Marketplace web site. See an example of the VM Service image for CentOS at VM Service Image for CentOS.
- Content Source
- A DevOps engineer uses a content library as a source of images to create a VM. Similar to VM classes, a vSphere administrator can assign existing content libraries to a namespace to make them available to DevOps engineers.
- Storage Class
- VM Service uses storage classes for placing virtual disks and dynamically attaching persistent volumes. For more information about storage classes, see Using Persistent Storage in vSphere with Tanzu.
- VM Specification
- DevOps engineers describe the desired state of a VM in a YAML file that brings together the VM image, the VM class, and the storage class.
- Networking
- VM Service does not have any specific requirements and relies on the network configuration available in vSphere with Tanzu. VM Service supports both types of networking, the vSphere networking or NSX-T. When VMs are deployed, an available network provider allocates static IP addresses to the VMs. For information, see Networking for vSphere with Tanzu.
vSphere Administrator Workflow for Provisioning a VM
As a vSphere administrator, you set guardrails for the policy and governance of the VMs, and deliver VM resources, such as VM classes and VM templates to DevOps engineers. After a VM is deployed, you can monitor it using the vSphere Client.
DevOps Engineer Workflow for Provisioning a VM
DevOps engineers with permissions, can review available VM resources and deploy VMs into the namespace. They use the kubectl command to perform the following tasks.
Step | Description | Instructions |
---|---|---|
1 | List VM classes, images, and other resources associated with the namespace. | View VM Resources Available on a Namespace in vSphere with Tanzu |
2 | Create a VM. |
|