The Manifest Owns the Machine

The AHV VM Operator puts a VM's desired state in Kubernetes. The tutorial shows who answers for it from then on.

The Manifest Owns the Machine

A virtual machine on AHV has always had one owner: whoever could see it in Prism Central. Declaring the same machine in Kubernetes adds a second place where its state lives, and which of the two is the truth is the whole operating model. When I wrote about NKP 2.19 on release day, the VM Operator was an announcement with no documentation behind it, so the article said so and moved on. On October 29 Nutanix.dev published a tutorial, and it answers the ownership question more clearly than a feature page would have.

What Shipped, and What Is Still Not Written

The availability line is short. The Nutanix blog of October 22 said the operator would be delivered through the NKP App catalog. The tutorial says it ships with NKP 2.19, which has been generally available since October 21. The resources live under vmm.v4.nutanix.com/v1alpha1 and prism.v4.nutanix.com/v1alpha1, and the 2.19 release notes and platform guide still do not mention the operator. The mechanism is settled enough to teach. The installation path still has to be written down, which is what a component delivered through the catalog rather than with the platform release tends to look like in its first weeks.

Two Resources, One Loop

The tutorial works with two primary custom resources that do different jobs. NutanixPrismContext, a namespaced resource, connects the cluster to a Prism Central endpoint, a credential secret and one Prism Central project, named explicitly in the spec. VirtualMachine references that context and declares the machine: sockets and cores, memory, an image-based boot disk, NICs on a subnet, the power state. The operator watches both, calls Prism Central, and writes the result back into the resource status: the external ID of the real VM, and a set of conditions, ContextBound, ResourcesResolved, Provisioned, PowerStateReady, AddressReady.

The VM the operator creates is an ordinary AHV machine that Prism Central manages, visible in the project; Kubernetes holds the desired configuration and the reported status, nothing runs inside a pod. Updating the machine is a patch to the resource, and the operator reconciles toward it. The tutorial’s example is memory, from 2Gi to 4Gi, and a resize that is a kubectl patch is the small, concrete thing a platform team will try first.

The Project Is the Boundary

The tutorial draws the division of responsibility in one sentence: infrastructure teams control projects, credentials, images, networks and capacity, application teams manage their VirtualMachine resources. The context is where that division becomes enforceable. A VM lands in the project its context names, with an image and a subnet that project is allowed to use, through a credential the application team does not have to hold. Self-service is bounded by the project, or more precisely by what someone already decided the project may consume.

I have argued in this series that the tenant exists before the control plane, and that on Nutanix the tenant is a Projects 2.0 project with its own resource limits. The operator is a third consumer of that decision. The first was Prism itself, the second was Projects 2.0 support in 2.19, which asks every Nutanix cluster to sit in one project. Now a machine declared from a Kubernetes namespace lands in the project the context points at, so a provider who kept tenants and projects aligned gets VM self-service for a tenant by handing it a context, and a provider who did not gets a reason to converge.

Delete the File, Lose the Machine

The sentence I would print and hang on the wall is in step 8. Deleting the Kubernetes resource deletes the corresponding VM in Prism Central, and the tutorial asks you to treat that as an infrastructure operation rather than the cleanup of an object. The same section warns against changing or deleting an operator-managed VM in Prism Central while its resource still exists, because the two states can drift. Put together, those two lines are the operating model: the manifest owns the machine, and Prism Central executes.

In a GitOps workflow that prunes what Git no longer declares, a pull request that removes a YAML file removes a server, with the same review that removes a ConfigMap. A deleted file is a quiet way to lose a machine. The tutorial does not describe a deletion guard on the resource, so manifest review and repository ownership are the safeguards I would put in place, which is where GitOps puts them anyway. I like that the tutorial says this out loud instead of leaving it to the first incident.

Arriving Ready

Arriving ready means clearing the tutorial’s prerequisites before the first context is applied. Prism Central 7.6 or later under an NKP 2.19 cluster with the operator and its CRDs installed. A project for the VMs, with the image and the subnet it will use already available to it. A credential secret, which in the example sits in ntnx-system, so decide who owns that namespace before the first context is applied. A subnet that provides DHCP or IPAM if the VM is to get an address on its own, because a VM can be Provisioned and powered on while AddressReady stays false, and the tutorial sends you to the subnet and to the guest’s network configuration when that happens. The example uses tls.mode: Insecure to stay short; in production, the TLS configuration is whatever your security standards require.

Two design choices are yours and the tutorial leaves them open. Which cluster runs the operator, since the sources do not say, and I would keep it off the management cluster for the same reason every other tenant-facing component stays off it. And whether pods need to reach those VMs by name: in the tutorial’s example VirtualMachineService selects VMs by label, publishes them through a ClusterIP with an endpoint probe, and stops treating powered-off or unreachable machines as ready backends in the EndpointSlice, which is the piece that turns a VM into a backend a pod can discover.

AHV still runs the machine and Prism Central still manages it. A file now holds its truth, and the project boundary you drew for tenants decides what that file may build.