13.1 vSphere VM Service: Classes, Images & Declarative Deployment
Key Takeaways
VM Service reconciles declared VirtualMachine resources through Supervisor controllers.
Classes specify compute and reservation policy; guaranteed CPU entitlement is not exclusive-core pinning.
Images, class access, networking and approved storage policy must be available to the target namespace.
Additional PVC-backed disks use the supported persistent-storage path; the VM boot disk is not universally an FCD.
Use the served API version and compatible bootstrap provider; Secret encoding is not encryption.
13.1 vSphere VM Service: Classes, Images & Declarative Deployment
Modern cloud-native software development emphasizes infrastructure-as-code, GitOps pipelines, and declarative configuration. Historically, enterprise virtualization forced a sharp divide between container workloads orchestrated through Kubernetes and traditional virtual machines managed through the vSphere Client, PowerCLI, or specialized IaaS portals. The vSphere VM Service eliminates this divide by integrating virtual machine lifecycle management directly into the vSphere Supervisor. By exposing the VM Operator within the Kubernetes control plane, vSphere enables platform engineers and developers to provision, power-cycle, reconfigure, and delete virtual machines using the same declarative Kubernetes API (kubectl apply) they use for containers.
Architecture of the vSphere VM Service
The vSphere VM Service operates as a set of Kubernetes controllers and Custom Resource Definitions (CRDs) deployed onto the Supervisor cluster. When an administrator enables Workload Management on a vSphere cluster, the VM Operator (vmoperator.vmware.com) is initialized across the Supervisor control plane nodes.
The VM Operator continuously reconciles the declared state specified in Kubernetes manifests with the actual state of virtual machines registered in vCenter Server. When a user submits a manifest of kind: VirtualMachine, the VM Operator coordinates with vCenter Server to clone the requested template from a Content Library, allocate virtual disks according to defined Storage Policies, attach network interfaces to appropriate distributed port groups or NSX overlay segments, inject guest bootstrap configuration, and power on the VM.
Core VM Service Building Blocks
Declarative virtual machine provisioning relies on four primary building blocks configured by the vSphere administrator and consumed by the developer:
1. VirtualMachineClass
A VirtualMachineClass defines the compute sizing envelope (virtual CPUs and memory) and hardware reservations allocated to a virtual machine. Sizing classes are managed globally by the vSphere administrator and subsequently granted to specific vSphere Namespaces.
VMware provides standard, pre-configured classes categorized by reservation semantics:
best-effort-*(e.g.,best-effort-small,best-effort-2xlarge): Allocates the specified vCPU and memory count with 0% resource reservation. The VM shares compute and memory capacity dynamically with other workloads on the ESXi host, subject to standard resource contention and swapping.guaranteed-*(e.g.,guaranteed-medium,guaranteed-4xlarge): Allocates the specified vCPU and memory count with 100% reservation for both CPU and memory. The class guarantees the specified CPU entitlement and memory reservation; it does not pin exclusive physical cores. A full memory reservation protects the reserved guest memory from host reclamation.
Administrators can also create Custom VirtualMachineClasses to accommodate specialized requirements, such as assigning specific NUMA node bindings, adding PCI passthrough devices, or configuring virtual GPU (vGPU) profiles for artificial intelligence and machine learning workloads.
2. VirtualMachineImage
A VirtualMachineImage represents a bootable operating system template packaged as an OVF or OVA. Images are stored in vSphere Content Libraries. To make images available to developers within a vSphere Namespace, the administrator associates one or more Content Libraries with that namespace. The VM Operator reads the library inventory and creates VirtualMachineImage (namespace-scoped) or ClusterVirtualMachineImage (cluster-scoped) resources in Kubernetes.
Each image resource exposes an imageCorrelationId or name attribute that developers reference directly in their deployment manifests. For automated provisioning to succeed, images should be cloud-init enabled (for Linux) or sysprep-ready (for Windows), allowing automated network and credential configuration during the first boot cycle.
3. StorageClass
Storage resources in the VM Service are mediated through standard Kubernetes StorageClass definitions. Each StorageClass corresponds directly to a vSphere Storage Policy Based Management (SPBM) policy assigned to the vSphere Namespace. When a virtual machine is provisioned, the VM Operator places VM storage according to the approved policy; additional PVC-backed disks use the supported CNS provisioning path on eligible datastores that comply with the underlying storage policy rules (such as RAID-1 mirroring, RAID-5/6 erasure coding, or encryption).
4. Network Configuration
The VM Service supports integration with both standard vSphere Distributed Switch (VDS) distributed port groups and VMware NSX overlay segments. When creating a vSphere Namespace, the administrator configures the network provider. Virtual machines deployed into the namespace automatically acquire IP addresses via DHCP, static IP pools defined in the namespace network configuration, or external IP Address Management (IPAM) systems.
Discover the Served API Before Writing a Manifest
Use kubectl api-resources and kubectl explain virtualmachine.spec against the target Supervisor. VM Operator APIs evolve independently; an old v1alpha1 example is not a universal 9.0 production manifest. Start from the example for the served version, then select class, image, namespace and storage policy that actually exist.
An illustrative modern VM Operator example, only where this API version is served, is:
apiVersion: vmoperator.vmware.com/v1alpha5
kind: VirtualMachine
metadata:
name: web-server-01
namespace: production-apps
spec:
className: best-effort-small
imageName: vmi-example-from-your-library
storageClass: example-approved-storage-class
bootstrap:
cloudInit:
cloudConfig: {}
The image and storage-class names above are placeholders, not deployable built-in resources. Adapt the network and bootstrap fields to the installed schema and compatible image. Use kubectl explain for nested fields, apply in the intended namespace, then inspect conditions/events. The VM Operator quickstart and guest-customization reference describe the API-specific structure.
An unknown field or unsupported API version is a schema problem. An image-not-found condition is a catalog problem. An insufficient-capacity condition is an allocation problem. Diagnose these separately rather than repeatedly changing the guest password.
Bootstrap and Protect Configuration
A compatible Linux image can consume cloud-init data; supported Windows images can use the applicable customization provider. Current bootstrap fields depend on the served API. Sensitive user data can reference a Secret under that provider's documented schema; the older spec.vmMetadata field must not be pasted into every modern API example.
Use image-compatible bootstrap configuration, approved user accounts and real authorized public keys. Do not treat a truncated example key as usable authentication. Avoid placing passwords in source control. Restrict Secret access because base64 encoding is not encryption, and keep bootstrap diagnostics from exposing credentials. Verify hostname, networking and application startup separately after infrastructure provisioning succeeds.
Lifecycle Operations & Day-2 Management
Once a virtual machine is declared, administrators and DevOps teams manage its lifecycle using standard kubectl commands:
| Operational Task | CLI Command | Mechanism / Behavior |
|---|---|---|
| Provision VM | kubectl apply -f vm.yaml | Creates VirtualMachine CR; VM Operator initiates cloning and hardware configuration in vCenter |
| Verify Deployment | kubectl get virtualmachines -n <ns> | Displays VM name, power state, assigned IP address, and operational readiness |
| Inspect Status | kubectl describe virtualmachine <name> | Outlines detailed status conditions (VirtualMachinePrereqReady, VMAllocationSucceeded, WaitingForIP) |
| Power Off VM | Edit spec.powerState: poweredOff | Reconciler executes clean guest shutdown or hard power-off via vSphere API |
| Vertical Scaling | Use the installed API's supported resize procedure | Verify allowed field changes, VM power state and capacity; editing a class name is not a universal resize workflow |
| Decommission VM | kubectl delete virtualmachine <name> | Removes the managed VM according to the controller; separately check persistent-volume ownership/reclaim policy and backup requirements |
Best-Effort vs Guaranteed VirtualMachineClass Profiles
Understanding the operational trade-offs between sizing classes is critical for architecting multi-tenant vSphere Foundation clusters:
| Architectural Attribute | best-effort-* Classes | guaranteed-* Classes |
|---|---|---|
| CPU Reservation | 0% (Shares-based scheduling) | 100% CPU entitlement; not exclusive core pinning |
| Memory Reservation | 0% (Swapping and ballooning permitted) | 100% (Locked in physical host RAM) |
| Consolidation Ratio | High (Supports compute overcommitment) | Reservations reduce overcommitment flexibility; no universal core-pinning ratio |
| Admission Control | Validates available unreserved capacity | Fails deployment if unreserved RAM/CPU is insufficient |
| Target Workload | Development, testing, batch processing, CI/CD runners | Production databases, ERP, latency-critical real-time applications |
| Admission Priority | Subject to ESXi host resource throttling during contention | Guaranteed configured entitlement; application latency still depends on the full system |
Review Takeaways
- VM Service reconciles declared VirtualMachine resources through Supervisor controllers.
- Classes specify compute and reservation policy; guaranteed CPU entitlement is not exclusive-core pinning.
- Images, class access, networking and approved storage policy must be available to the target namespace.
- Additional PVC-backed disks use the supported persistent-storage path; the VM boot disk is not universally an FCD.
- Use the served API version and compatible bootstrap provider; Secret encoding is not encryption.
Which VM class category reserves its defined CPU and memory entitlement?
A guaranteed class; CPU reservation is not exclusive core pinning
A best-effort class with no reservations
A content-library image alone
A storage class alone
An administrator needs to make a newly created golden Linux OS template available for declarative deployment via the vSphere VM Service within the 'dev-workloads' vSphere Namespace. Which administrative procedure achieves this requirement?
Export the VM as a flat VMDK file and manually copy it via SCP to the root directory of the primary ESXi host
Store the OVF/OVA template in a vSphere Content Library and associate that Content Library with the target vSphere Namespace
Upload the raw ISO image directly into a Kubernetes ConfigMap within the 'kube-system' namespace
Execute 'kubectl create secret docker-registry' using the root credentials of the vCenter Server Appliance
Before adding cloud-init data to a VM Service manifest, what must the developer verify?
That every cluster uses v1alpha1
That ESX stores the payload in its boot bank
The served VM Operator API schema and an image-compatible bootstrap provider/Secret reference
That a VM can only boot by PXE
Sections you finish are checked off in the contents.