The Modern Compute Primitive: Why Declarative VM Management Matters Now (Introducing KubeVM Service)

If you look at most enterprise production environments, there is still a noticeable gap: platform teams deploy Kubernetes workloads through GitOps pipelines, while VM provisioning still lives in a separate workflow, whether that’s a Terraform run, a PowerCLI script, or an internal ticketing queue.

The answer isn’t forcing teams to convert stable databases into stateful pods or migrating workloads for the sake of modernization. VMs remain the right compute primitive for many mission-critical enterprise systems, core databases, and backend processing engines today. Modernizing infrastructure doesn’t require a multi-million-dollar “rip-and-replace” effort.

What needs to change isn’t where virtual machines run, but how platform teams consume and manage them.

Now, with the rapid emergence of generative AI agents and specialized workstations, new use cases are reinforcing the importance of VMs as a modern compute primitive. We’re introducing KubeVM Service, bringing declarative, Kubernetes-native lifecycle management to VMs running directly on ESX.

With KubeVM Service, Kubernetes provides the developer-facing API and reconciliation model, while VMware Cloud Foundation (VCF) continues to provide the virtualization capabilities, operational visibility, and governance enterprises depend on.

Two Operational Realities: Bridging Infrastructure Automation and Developer GitOps

In any enterprise, workloads naturally fall into two distinct operational categories:

1. Static, Steady-State Workloads: Core enterprise applications, long-standing relational databases, and legacy appliances often undergo infrequent changes. These systems run reliably under vCenter management and battle-tested automation frameworks like VMware PowerCLI, Terraform, or Ansible. They do not need the additional operational overhead of a Kubernetes-driven pipeline, and managing them through proven day-2 operations remains completely valid.
2. Dynamic, Platform-Centric Workloads: Developer sandboxes, CI/CD runners, and modern AI environments require rapid iteration, continuous self-service, and programmatic scaling.

The challenge today is that platform engineering and application teams have standardized on a completely different operational plane: the Kubernetes API and GitOps.

The friction comes down to control plane divergence. When platform teams build Internal Developer Platforms on Backstage or Argo CD, having VMs sit outside the Kubernetes resource model breaks automation:

• Toolchain Fragmentation: Application services live in declarative Git repositories, while VM provisioning often remains locked behind disparate procedural scripts, siloed Terraform runs, or infrastructure ticketing queues.
• Drift Detection: Traditional infrastructure-as-code tools typically detect and remediate drift when a plan or automation workflow executes. Kubernetes controllers continuously observe actual state and reconcile it against the declared specification, providing a different operational model for managing infrastructure.
• Platform Standardization: Modern developer platforms (including Argo CD, Flux, Backstage portals) are built directly on the Kubernetes resource model.

KubeVM Service does not ask enterprises to replace their existing automation or force static workloads into Kubernetes. Instead, it exposes native virtual machines directly through the Kubernetes API, allowing platform teams to consume and manage dynamic VMs alongside pods using the declarative workflows they already rely on every day.

Why AI Workloads Are Renewing Interest in VMs

A few years ago, the common consensus was that virtualization was merely a stepping stone toward containers. Generative AI has upended that assumption.

Enterprise platforms already have established primitives for containerized software. Standard containers handle stateless microservices, while vSphere Pods provide hypervisor-grade isolation for container runtimes without the overhead of managing a guest OS. However, emerging AI use cases introduce requirements where dedicated operating systems, independent kernels, and stronger workload isolation can offer distinct advantages:

Autonomous Agents and Dynamic Sandboxes: When an autonomous agent compiles and executes arbitrary code or an AI desktop agent interacts with graphical applications, isolation and operating system flexibility become critical. While containers can support many of these scenarios, workloads requiring kernel-level customization, privileged system operations, nested container runtimes, or complete desktop environments can benefit from a dedicated VM. KubeVM Service provides a disposable, isolated guest OS environment that platform teams and agent orchestrators can provision, control, and terminate on demand through standard Kubernetes manifests.

Interactive AI and Data Science Workstations: Data scientists and AI researchers often require high-performance environments with dedicated GPU access, custom CUDA dependencies, and persistent development environments. Containers remain an effective option for many AI development workflows, but VMs provide greater flexibility when users need full control over the operating system, system-level dependencies, and long-lived workstation configurations. KubeVM Service enables self-service, GPU-accelerated workstations managed declaratively through Kubernetes and GitOps.

Direct Hardware Acceleration: Certain AI training and inference workloads benefit from direct access to GPU hardware and specialized interconnects. Hypervisor-level device passthrough can provide direct access to supported accelerators while preserving the operational capabilities of enterprise virtualization. KubeVM Service enables platform teams to provision these VM-based environments through a Kubernetes-native API without requiring the workloads themselves to run as containers.

Preserving Existing Security Controls

One of the largest hidden costs of cloud-native modernization is security policy re-engineering.

Enterprise security teams have spent years building operational processes, security policies, and compliance controls around VMs. For organizations with established VM-based security frameworks, introducing a new workload execution model can require additional validation and operational changes.

VMs provide a dedicated guest kernel and familiar infrastructure-level controls, including virtual networking, resource isolation, and integration with existing security tooling. These capabilities can be particularly valuable for workloads that execute untrusted code or require stronger separation between operating system environments.

KubeVM Service allows platform teams to introduce Kubernetes-native self-service while continuing to leverage established security and operational controls. This provides a practical path to modernize infrastructure consumption without requiring organizations to redesign their existing governance model.

What Is Declarative VM Management?

To understand how KubeVM Service operates, it helps to contrast imperative infrastructure with declarative orchestration.

• Imperative Management (Traditional): You tell the system how to build something step-by-step: “Create a VM, name it DB-01, allocate 4 vCPUs, attach 32GB RAM, connect to VLAN 10, power it on.” If step four fails, the process stops, leaving a half-configured, unmonitored zombie instance.
• Declarative Management (KubeVM Service): You declare the desired end state: “I require a VM with 4 vCPUs, 32GB RAM, running Ubuntu 24.04, with its power state PoweredOn.” A continuous reconciliation loop ensures that reality matches this declaration at all times.

Operational Dimension	Imperative (Traditional VM Management)	Declarative (KubeVM Service)
Operational Model	Sequential scripts (Perl, Bash, PowerCLI) or manual UI clicks	Continuous desired-state reconciliation via Kubernetes controllers
Control Plane	Infrastructure-specific consoles, specialized APIs, or tickets	Standard Kubernetes API (kubectl, ArgoCD, Flux)
Configuration Drift	Drift detection through scheduled plans or automation workflows	Continuous monitoring; actively restores drifted state to manifest
Pipeline Integration	Integration through infrastructure-specific automation and CI/CD tooling	Native GitOps integration; versioned, auditable, and rollback-ready
Security & Tenancy	Managed out-of-band with manual firewall tickets	Namespace-scoped RBAC, hardware quota enforcement, and native VM boundaries

Kubernetes-Native Management, Native ESX Execution

A key architectural distinction of KubeVM Service is the separation between the Kubernetes control plane and the underlying VM execution environment.

Kubernetes provides the declarative API, desired-state reconciliation, and integration with GitOps workflows. The VMs themselves run natively on ESX, rather than being encapsulated inside Kubernetes worker-node pods.

This allows platform teams to provision and manage VMs using familiar Kubernetes tools while retaining the native virtualization capabilities of VCF, including vCenter visibility, vMotion, DRS, storage policies, and established day-2 operations.

Consider a platform team providing temporary development environments. A developer requests a VM through an internal portal, the request becomes a Kubernetes resource, and the controller provisions the VM on the existing VCF infrastructure. The developer works through the same self-service interface used for other platform resources, while the infrastructure team continues to manage capacity, storage policies, and operational visibility through VCF.

In other words, Kubernetes defines and manages the desired state, while VCF continues to operate the underlying virtual infrastructure.

Behind this manifest, the VM lifecycle controller translates the high-level specification into native ESX primitives, binding to the pre-defined vCenter storage policy, provisioning the virtual hardware matching className, and mounting the cloud-init payload via guest info.

From the platform engineer’s perspective, provisioning or resizing a VM is simply a Git commit. From the VI admin’s perspective, it appears in vCenter with standard resource pool limits, storage policies, and DRS rules fully applied.

Platform engineering teams can store this YAML in a central Git repository. Infrastructure changes, resizing, and teardowns occur via standard pull requests, bringing the entire VM fleet into the modern platform engineering lifecycle.

Built for Platform Governance: Guardrails Meet Self-Service

By embedding VMs natively into the Kubernetes control plane, KubeVM Service helps bridge the gap between infrastructure control and developer velocity:

• Role-Based Separation of Concerns: VI and infrastructure admins curate and govern the platform guardrails, defining allowable VM Classes (e.g., CPU, RAM, and GPU configurations), attaching approved storage policies (VMware vSAN, NVMe), and setting strict resource quotas. Within those boundaries, developers and data scientists gain complete self-service through GitOps without filing infrastructure tickets or risking cluster over-subscription.
• Zero-Touch Bootstrapping via cloud-init: By supporting native cloud-init user-data configurations backed by Kubernetes Secrets and ConfigMaps, guest customization (injecting SSH keys, hostnames, network settings, and pre-installed packages) is completely declarative. This reduces the need for custom post-provisioning scripts.
• Full Day-2 Enterprise Continuity: Because these workloads run as native hypervisor VMs rather than container-wrapped abstractions, existing enterprise investments remain fully operational on day one. Enterprise backup solutions back them up via standard hypervisor APIs, and monitoring tools (like VMware Cloud Foundation Operations) track them without requiring custom pod-level monitoring agents.

Brownfield Coexistence: Built for New Workloads, Flexible for Existing Fleets

A common concern with platform modernization is the fear of an “all-or-nothing” mandate. Infrastructure leaders worry that adopting declarative tooling requires retrofitting thousands of steady-state virtual machines or pushing traditional operations into Kubernetes before teams are ready.

KubeVM Service is architected around brownfield realities:

• Primary Focus on Modern Consumption: The core mission of KubeVM Service is enabling self-service provisioning for new applications, internal developer platforms (IDPs), and dynamic AI workloads. You do not need to embark on a massive migration project or alter stable systems to start delivering cloud-native velocity.
• Side-by-Side Coexistence: Declarative VMs managed via GitOps run on the exact same vSphere clusters, networks, and storage policies alongside traditional VMs managed directly through vCenter. Adopting modern developer workflows doesn’t require separate hardware or operational silos.
• Pragmatic Onboarding for Existing VMs: While the strategic focus is modern consumption, reality isn’t always greenfield. For teams where unified governance is critical, KubeVM Service allows you to bring existing virtual machines under declarative management without having to migrate workloads, re-IP systems, or disrupt where they run. This gives platform teams the flexibility to fold critical existing databases or stateful backends into modern GitOps pipelines at their own pace.
• Zero Disruption to Traditional Operations: VI administrators retain complete visibility and operational control inside vCenter. Teams can introduce declarative capabilities where they provide immediate business value, while leaving existing steady-state workloads running untouched under proven day-2 operations.

Enterprise Value: Modern Developer Velocity Without Infrastructure Overhead

By bridging native VMs into the Kubernetes control plane, organizations unlock critical advantages without changing day-2 operations:

• Native Enterprise Hypervisor Integration: Because VMs run directly on ESX, KubeVM Service preserves access to native VCF capabilities such as vMotion, DRS, storage policies, and established infrastructure operations. Platform teams gain Kubernetes-native VM lifecycle management without changing the underlying virtualization architecture.
• No Black-Box VMs: While developers manage VMs via kubectl and GitOps, these resources remain visible to infrastructure teams inside vCenter. VI admins retain complete visibility for capacity planning, backup policies, performance diagnostics, and operational governance.
• Automated FinOps and Lifecycle Control: KubeVM Service enables platform teams to define expiration policies for temporary VMs through declarative specifications, metadata, or policy engines such as Kyverno and OPA. Combined with health monitoring through VMware Tools and Kubernetes resource status, these capabilities provide visibility into VM health and lifecycle state. Platform teams can configure automated actions, including shutting down or deleting expired environments and remediating unhealthy VMs, helping reduce unnecessary resource consumption and operational overhead.
• In-Place Operational Modernization: Rather than undertaking high-risk re-platforming initiatives, platform teams can bring declarative management directly to their existing infrastructure footprint. Because workloads remain standard VMs, applications run without code modifications or containerization mandates, reducing the effort required to modernize existing environments.

The Road Ahead

Virtual machines and containers are not competing paradigms; they are complementary compute primitives governed by the same platform principles. KubeVM Service brings virtual machines into the modern cloud-native era, giving developers declarative speed while giving infrastructure and security teams the isolation, stability, and governance they trust.