Deploying a Stand-Alone VM in vSphere IaaS Control Plane

As a DevOps engineer, use the kubectl command to review available VM resources and provision a stand-alone Linux or Windows VM in a namespace on a Supervisor. If the VM includes a PCI device configured for vGPU, after you create and boot the VM in your vSphere IaaS control plane environment, you can install the NVIDIA vGPU graphics driver to enable GPU operations.

Prerequisites

To be able to deploy a stand-alone VM in vSphere IaaS control plane, a DevOps engineer must have access to specific VM resources. Make sure that a vSphere administrator has performed these steps to make VM resources available:

Create a namespace and assign storage policies to it. See Create and Configure a vSphere Namespace on the Supervisor.
Create a content library and associate it with the namespace. See Creating and Managing Content Libraries for Stand-Alone VMs in vSphere IaaS Control Plane.
- If a content library is protected by a security policy, all library items must be complaint. If the protected library includes a mix of compliant and non-compliant items, the kubectl get virtualmachineimages command fails to present VM images to the DevOps engineers.
- If you plan to deploy VMs with vGPU devices, you must have access to images with the boot mode set to EFI, such as CentOS.
Associate default or custom VM classes with a namespace. See Working with VM Classes in vSphere IaaS Control Plane.

If you plan to use NVIDIA vGPU or other PCI devices for your VMs, you must follow additional requirements. For information, see Deploying a VM with PCI Devices in vSphere IaaS Control Plane.

For information about VM operator and supported fields, see Concepts of VM Service and https://vm-operator.readthedocs.io/en/stable/ref/api/v1alpha2/.

View VM Resources Available on a Namespace in vSphere IaaS Control Plane

As a DevOps engineer, verify that you can access VM resources on your namespace, and view VM classes and VM templates available in your environment. You can also list storage classes and other items you might need to self-service a VM.

This task covers commands you use to access resources available for a deployment of a stand-alone VM. For information about resources necessary to deploy TKG clusters and VMs that make up the clusters, see Virtual Machine Classes for TKG Clusters in the Using TKG Service with vSphere IaaS Control Plane documentation.

Procedure

Access your namespace in the Kubernetes environment.
See Get and Use the Supervisor Context in vSphere IaaS Control Plane.
To view VM classes available in your namespace, run the following command.
kubectl get virtualmachineclass
You can see the following output.

Note: Because the best effort VM class type allows resources to be overcommitted, you can run out of resources if you have set limits on the namespace where you are provisioning the VMs. For this reason, use the guaranteed VM class type in the production environment.
```
NAME                       VIRTUALMACHINECLASS        AGE

best-effort-large          best-effort-large          44m
best-effort-medium         best-effort-medium         44m
best-effort-small          best-effort-small          44m
best-effort-xsmall         best-effort-xsmall         44m
custom                     custom                     44m
```
To view details of a specific VM class, run the following commands.
- kubectl describe virtualmachineclasses name_vm_class
  If a VM class includes a vGPU device, you can see its profile under spec: hardware: devices: vgpuDevices.
```
......
spec:
  hardware:
    cpus: 4
    devices:
      vgpuDevices:
      - profileName: grid_v100-q4
......
```
- kubectl get virtualmachineclasses -o wide
  If the VM class includes a vGPU or a passthrough device, the output shows it in the VGPUDevicesProfileNames or PassthroughDeviceIDs column.

View the VM images.

kubectl get virtualmachineimages

The output you see is similar to the following. The image name, such as vmi-xxxxxxxxxxxxx is auto-generated by the system.

NAME                                              VERSION  OSTYPE                FORMAT  IMAGESUPPORTED  AGE
vmi-xxxxxxxxxxxxx                                          centos8_64Guest       ovf     true            4d3h

To describe a specific image, use the following command.
kubectl describe virtualmachineimage vmi-xxxxxxxxxxxxx
VMs with vGPU devices require images that have boot mode set to EFI, such as CentOS. Make sure to have access to these images.

Verify that you can access storage classes.

kubectl get resourcequotas

Note: VM Service VMs cannot use storage classes with WaitForFirstConsumer volume binding mode ending with -latebinding.

For more information, see Display Storage Classes in a vSphere Namespace.

NAME                        AGE   REQUEST                                                                                         LIMIT
my-ns-ubuntu-storagequota   24h   wcpglobal-storage-profile.storageclass.storage.k8s.io/requests.storage: 0/9223372036854775807

Deploy a Virtual Machine in vSphere IaaS Control Plane

As a DevOps engineer, provision a VM and its guest OS in a declarative manner by writing VM deployment specifications in a Kubernetes YAML file.

Prerequisites

If you use NVIDIA vGPU or other PCI devices for your VMs, see Deploying a VM with PCI Devices in vSphere IaaS Control Plane.

Procedure

Prepare a VM YAML file.

In the file, specify the following parameters:

Option	Description
apiVersion	Specifies the version of the VM Service API. Such as `vmoperator.vmware.com/v1alpha2`.
kind	Specifies the type of Kubernetes resource to create. The only available value is `VirtualMachine`.
spec.imageName	Specifies the virtual machine image resource name in Kubernetes cluster.
spec.storageClass	Specifies the storage class to be used for storage of the persistent volumes.
spec.className	Specifies the name of the VM class that describes the virtual hardware settings to be used.
spec.networkInterfaces	Specifies network-related settings for the VM. networkType. Values for this key can be `nsx-t` or `vsphere-distributed`. networkName. If needed, specify the name or leave the default name.
spec.vmMetadata	Includes additional metadata to pass to the VM. You can use this key to customize the guest OS image and set such items as the hostname of the VM and user-data, including passwords, ssh keys, and so on. For additional information, including details on how to bootstrap and customize Windows VMs using the Microsoft System Preparation tool (Sysprep), see Customizing a Guest.
topology.kubernetes.io/zone	Controls the VM placement on a three-zone Supervisor. For example, topology.kubernetes.io/zone: zone-a02.

The following example VM YAML file my-vm uses CloudInit as a bootstrapping method. The example shows a VirtualMachine resource that specifies user data in a Secret resource my-vm-bootstrap-data. The Secret will be used to bootstrap and customize the guest OS.

The data in the Secret includes the CloudInit cloud-config. For more information on the cloud-config format, see the Cloud config examples official documentation.

For examples with Sysprep as a bootstrapping method, see Sysprep.

apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
  name:      my-vm
  namespace: my-namespace
spec:
  className:    small
  imageName:    vmi-xxxxxxxxxxxxx
  storageClass: iscsi
  vmMetadata:
    transport: CloudInit
    secretName: my-vm-bootstrap-data

apiVersion: v1
kind: Secret
metadata:
  name:      my-vm-bootstrap-data
  namespace: my-namespace
stringData:
  user-data: |
    #cloud-config
    users:
    - default
    - name: xyz..
      primary_group: xyz..
      groups: users
      ssh_authorized_keys:
      - ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDSL7uWGj...
    runcmd:
    - "ls /"
    - [ "ls", "-a", "-l", "/" ]
    write_files:
    - path: /etc/my-plaintext
      permissions: '0644'
      owner: root:root
      content: |
        Hello, world.

Use the following example if you are deploying a VM in an environment with zones.

To get the values for ZONE_NAME, run the kubectl get vspherezones command.

apiVersion: vmoperator.vmware.com/v1alpha2
kind: VirtualMachine
metadata:
  name: <vm-name>
  namespace: <vm-ns>
  labels:
    topology.kubernetes.io/zone: ZONE_NAME
...

Deploy the VM.
```
kubectl apply -f my-vm.yaml
```

Verify that the VM has been created.

kubectl get vm
NAME              AGE
my-vm             28s

Check the VM details and its status.

kubectl describe virtualmachine my-vm

The output is similar to the following. From the output, you can also obtain the IP address of the VM, which appears in the Vm Ip field.

Name:         my-vm
Namespace:    my-namespace
API Version:  vmoperator.vmware.com/v1alpha2
Kind:         VirtualMachine
Metadata:
  Creation Timestamp:  2021-03-23T19:07:36Z
  Finalizers:
    virtualmachine.vmoperator.vmware.com
  Generation:  1
  Managed Fields:
 ...  
 ... 
Status:
  Bios UUID:              4218ec42-aeb3-9491-fe22-19b6f954ce38
  Change Block Tracking:  false
  Conditions:
    Last Transition Time:  2021-03-23T19:08:59Z
    Status:                True
    Type:                  VirtualMachinePrereqReady
  Host:                    10.185.240.10
  Instance UUID:           50180b3a-86ee-870a-c3da-90ddbaffc950
  Phase:                   Created
  Power State:             poweredOn
  Unique ID:               vm-73
  Vm Ip:                   10.161.75.162
Events:                    <none>
...

Verify that the VM IP is reachable.

ping 10.161.75.162
PING 10.161.75.162 (10.161.75.162): 56 data bytes
64 bytes from 10.161.75.162: icmp_seq=0 ttl=59 time=43.528 ms
64 bytes from 10.161.75.162: icmp_seq=1 ttl=59 time=53.885 ms
64 bytes from 10.161.75.162: icmp_seq=2 ttl=59 time=31.581 ms

Results

A VM created through the VM Service can be managed only by DevOps from the Kubernetes namespace. Its life cycle cannot be managed from the vSphere Client, but vSphere administrators can monitor the VM and its resources. For more information, see Monitor Virtual Machines Available in vSphere IaaS Control Plane.

What to do next

For additional details, see the Introducing Virtual Machine Provisioning blog.