This guide puts it in one place. For each item, you get:

• what it creates, and the YAML behind it;
• every field the platform accepts;
• a minimal snippet, and recipes for the common jobs;
• the status fields worth reading;
• the traps we hit.

Three things make it more than a list from memory, which, given my memory, is just as well:

• The field lists come from the platform. VCF Automation publishes the schema of every blueprint resource type through its API. The designer carries the schema of every palette item. The Supervisor publishes the definition of every Kubernetes kind it serves, and VCF Automation’s VPC API publishes its own. Where they disagree (and they do), the tables follow what the platform enforces.
• Every snippet was checked. Each one went through VCF Automation’s validation API, and every Kubernetes manifest through a server-side dry run on the Supervisor. Five test blueprints (all of them in the downloads) deployed every item for real. The remaining recipes are ones our lab catalog deploys every day.
• The traps are real. Several of the most useful lines in this guide come from things that went wrong while testing: a NAT rule that ignored its port, a firewall rule that grew an “Any”, a request that waits for an address that can never come.

We checked it on our lab platform, f06:

• VCF Automation 9.1.0;
• a Supervisor on Kubernetes 1.32.9, with the VM Operator API at v1alpha5;
• VKS with ClusterClasses up to builtin-generic-v3.6.0, and Kubernetes releases up to 1.35.5;
• NSX VPCs.

Names in the examples (f06, nested-pod, vpc-student05, vsan-default-storage-policy) are ours; use yours.

In the field tables, Values gives a field’s choices and default. Where the schema has neither, it gives an example, marked e.g.: the value from our tested blueprints wherever one of them set the field, otherwise a typical one. For an object or a list, the example is a short YAML flow value built from its fields (... marks the ones left out). And <...> stands for a name of yours.

The shape of a blueprint

An All Apps blueprint is YAML with formatVersion: 2, its inputs, its resources and its outputs:

formatVersion: 2
inputs:
  vmName:
    type: string
    title: VM name
    default: web-01
    pattern: '^[a-z0-9]([-a-z0-9]*[a-z0-9])?$'
  size:
    type: string
    title: Size
    default: small
    oneOf:
      - {title: Small, const: small}
      - {title: Medium, const: medium}
resources:
  namespace:
    type: CCI.Supervisor.Namespace
    properties:
      name: team-a-dev
      existing: true
  vm1:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha5
        kind: VirtualMachine
        metadata:
          name: ${input.vmName}
        spec:
          className: ${'best-effort-' + input.size}
          imageName: ubuntu-24.04-server-cloudimg-amd64
          storageClass: vsan-default-storage-policy
outputs:
  vmName:
    value: ${resource.vm1.object.metadata.name}

What the expressions can read:

Besides type and properties, each resource has dependsOn (an explicit order) and allocatePerInstance (see count below). formatVersion: 2 also allows metadata, variables, and an output named __deploymentOverview, whose Markdown value becomes the deployment’s overview page.

How the palette maps to YAML

Behind the sixteen items there are only five resource types, and one of them isn’t in the palette. Most items are a type with part of its YAML already filled in. For the workload items, that’s a Kubernetes apiVersion and kind; for the VPC items, it’s a VPC configuration kind.

Four consequences, worth knowing before any of the detail:

• Anything the Supervisor understands can go in a blueprint. The workload items are shortcuts. The generic Supervisor Resource takes any manifest the namespace accepts. Our lab blueprints rely on a kind the palette doesn’t offer, SubnetConnectionBindingMap, to carry VLANs.
• The VPC items are a closed list. CCI.VPC.Configuration takes exactly the five kinds above. A VPC’s load balancer is a sixth kind in VCF Automation’s VPC API, and a blueprint can’t make one (see VPC).
• VCF Automation validates the outside, the platform the inside. The validation API checks the resource type’s own properties: required fields, patterns, the namespace’s two shapes. It doesn’t look inside a manifest or a configs[].spec: in our test, powerState: Sideways passed validation. Those are checked when the request runs.
• The designer’s schemas are not the platform’s. The palette’s forms come from schemas bundled with VCF Automation, while the Supervisor and the VPC API check against their own. They disagree in a handful of places, listed next.

Where the designer and the platform disagree

We compared each palette item’s schema with the platform’s definition of the same apiVersion and kind. We went field by field (every bit as gripping as it sounds) and tested every difference:

None of this stops the designer from saving a blueprint. It surfaces when the request runs.

What every resource shares

Properties on every type

Recipe, two Secrets from one resource:

  sec:
    type: CCI.Supervisor.Resource
    allocatePerInstance: true
    properties:
      count: 2
      context: ${resource.ns.id}
      manifest:
        apiVersion: v1
        kind: Secret
        metadata:
          name: ${'ref-s-' + count.index}
        type: Opaque
        stringData:
          note: created by instance ${count.index}

The deployment then holds sec[0] and sec[1], and the namespace ref-s-0 and ref-s-1.

wait: when a resource is finished

Without a wait, a Supervisor Resource is finished as soon as the Supervisor accepts the manifest. That’s fine for a Secret, and wrong for a VM whose address an output needs. wait takes conditions, fields, or both:

      wait:
        conditions:                      # status.conditions[] of the object
          - type: Ready
            status: "True"
          - type: Ready
            status: "False"
            reason: Failed
            indicatesFailure: true       # this one fails the resource instead of finishing it
        fields:                          # any field of the object, by path
          - path: status.powerState
            value: PoweredOn
        skipWaitOnDelete: false          # true: deletion does not wait for the object to be gone

A Supervisor Resource can also watch log output with executionLogs: progressMessagePattern while a matching message appears, and failureMessagePattern to fail the resource.

The designer pre-fills a wait for some items:

The VM’s default came from a 9.0 problem: VM status could come back empty, and Broadcom’s KB 435137 gave this wait as the workaround. That condition is true before the VM is even on, let alone has an address.

VCF Automation also waits by itself in one place: a Virtual Machine Service of type LoadBalancer is not finished until it has an external address, with or without a wait. In a VPC without a load balancer, that address never comes, and the request stays in progress until it times out. Ours was still PARTIAL after ten minutes, with the service <pending> on the Supervisor.

Reading a resource’s live state

Every Supervisor Resource exposes the object as the Supervisor sees it under object, and a VPC Configuration exposes its objects under configs:

outputs:
  vmIp:
    value: ${resource.vm1.object.status.network.primaryIP4}
  vmHost:
    value: ${resource.vm1.object.status.nodeName}
  lbIp:
    value: ${resource.webLb.object.status.loadBalancer.ingress[0].ip}
  publicIp:
    value: ${resource.publicIp.configs[0].spec.allocationIPs}

Outputs are computed once, when the request finishes, and not refreshed afterwards. A VM that waited only for PoweredOn finished before its guest reported an address, and its IP output stayed empty for good. Waiting on the condition that marks the guest’s network as configured fixes it. This one gave the output 172.30.0.2:

      wait:
        conditions:
          - type: VirtualMachineGuestNetworkConfigSynced
            status: "True"

Checking a manifest before you deploy it

The fastest check we found is a server-side dry run with strict field validation, against the namespace the blueprint will use:

kubectl apply --dry-run=server --validate=strict -n <namespace> -f vm.yaml

It runs the Supervisor’s schema checks and admission webhooks, flags unknown fields, and creates nothing. It works for every workload kind. It does not work for the VPC kinds: VCF Automation’s VPC API ignores dryRun and creates the object, as one of our probes found.

Supervisor Namespace

type: CCI.Supervisor.Namespace. Creates a vSphere Namespace through VCF Automation, inside the project’s allocation, or adopts one that exists. Everything in the Workload group needs one: their context points at it.

The schema has two shapes, and the validator enforces them: an existing namespace takes name and existing: true and nothing else; a new one needs generateName, className, regionName and vpcName.

Minimal, a new namespace with the zone and storage our class doesn’t set:

  namespace:
    type: CCI.Supervisor.Namespace
    properties:
      generateName: ns-demo
      className: nested-pod
      regionName: f06
      vpcName: vpc-student05
      storageClasses:
        - name: vSAN Default Storage Policy
          limit: 100Gi
      zones:
        - name: domain-c9
          cpuLimit: 4000M
          cpuReservation: 0M
          memoryLimit: 8192Mi
          memoryReservation: 0Mi

Recipes

• A quota sized from the request, so a namespace never outgrows what was asked for. Our lab blueprints compute the limits from the requested sizes:

      storageClasses:
        - name: vSAN Default Storage Policy
          limit: "${input.hosts * 200 + 'Gi'}"
      zones:
        - name: domain-c9
          cpuLimit: "${input.hosts * 8000 + 'M'}"
          cpuReservation: 0M
          memoryLimit: "${input.hosts * 32768 + 'Mi'}"
          memoryReservation: 0Mi
  

• Deploy into a namespace that already exists, for example one an administrator prepared:

  namespace:
    type: CCI.Supervisor.Namespace
    properties:
      name: team-a-dev
      existing: true
  

Status worth reading: ${resource.<ns>.id} is cci:<project>:<namespace>, which context takes.

Gotchas

• Whether zones and storageClasses are optional depends on the namespace class. Ours sets neither, and VCF Automation refused the minimal shape in turn: Zone should be specified in Namespace or in Namespace class, then Storage Class should be specified in Namespace or in Namespace class.
• The zone name is the vSphere Zone. A Supervisor without zones still has one, named after its cluster (domain-c9 on f06).
• A VM can only use a VM class the namespace allows and an image from its content sources. The validator cannot know either; the request finds out.

VPC

type: CCI.VPC. Creates an NSX VPC in a region. Most blueprints use an existing VPC, through the namespace’s vpcName. This item is for a blueprint that brings its own network.

  vpc:
    type: CCI.VPC
    properties:
      generateName: vpc-app
      regionName: f06
      privateIPs:
        - 10.200.0.0/20

Status worth reading: id (cci:vpc:<project>:<name>), which every VPC Configuration takes as vpc, and name, which a namespace takes as vpcName.

Gotchas

• A new VPC reaches nothing outside itself until it has an Attachment to a VPC connectivity profile; give the namespace dependsOn on the attachment.
• privateIPs must not overlap the connectivity profile’s Private Transit Gateway blocks, and the error only comes at attachment time: private IP CIDR 172.31.64.0/20 overlaps with private TGW IP block CIDR 172.31.0.0/16.
• A blueprint cannot give its VPC a load balancer. In VCF Automation’s VPC API the load balancer is its own kind, LoadBalancer, and CCI.VPC.Configuration refuses it: Failed to match exactly one schema (matched 0 out of 5). Without one, a LoadBalancer service never gets an address (and its request never finishes, see wait), and Broadcom’s VPC page warns that a VPC without load balancing cannot run VKS. For either, use a VPC made in the UI with Enable load balancing on, and name it in the namespace’s vpcName.

VPC Configuration

type: CCI.VPC.Configuration. One item for every object that lives inside a VPC, and kind chooses which. The five palette entries below are this item with kind filled in. Each configs[] entry becomes one object, so one resource can create several rules or groups of the same kind.

Three things hold for all five kinds:

• generateName is the name, not a prefix. VCF Automation names the object <vpc>:<generateName>, as written: our group was vpc-ref-default-project-y3698:web. Keep it unique per kind in the VPC.
• VCF Automation fills in spec.vpcName and spec.regionName from the vpc property; leave them out.
• Another resource reads an object as configs[n]: ${resource.webGroup.configs[0].name} is the full name a firewall rule needs, and ${resource.publicIp.configs[0].spec.allocationIPs} is the address an allocation got.

The shape, for every kind:

  natRules:
    type: CCI.VPC.Configuration
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCNATRule
      configs:
        - generateName: dnat-web
          spec: { ... }
        - generateName: dnat-ssh
          spec: { ... }

Attachment

kind: VPCAttachment. Attaches the VPC to a VPC connectivity profile, which decides its transit gateway, its external IP blocks and whether it gets a default outbound NAT.

  attach:
    type: CCI.VPC.Configuration
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCAttachment
      configs:
        - generateName: attach
          spec:
            vpcConnectivityProfileName: default--f06

With the attachment realized, NSX adds the VPC’s default SNAT rule and its address by itself (ours: 10.200.0.0/20 to 192.168.144.14).

IP Address Allocation

kind: VPCIPAddressAllocation. Reserves addresses from one of the VPC’s IP blocks, typically an external address for a NAT rule.

  publicIp:
    type: CCI.VPC.Configuration
    dependsOn: [attach]
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCIPAddressAllocation
      configs:
        - generateName: web-ip
          spec:
            ipAddressBlockVisibility: External
            allocationSize: 1

The allocated address appears in the object’s own spec: ${resource.publicIp.configs[0].spec.allocationIPs} gave 192.168.144.18. An external allocation needs the attachment first, hence the dependsOn.

NAT Rule

kind: VPCNATRule. A NAT rule on the VPC’s gateway. The designer’s default wait is Realized.

  dnatSsh:
    type: CCI.VPC.Configuration
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCNATRule
      configs:
        - generateName: dnat-ssh
          spec:
            action: DNAT
            destinationNetwork: ${resource.publicIp.configs[0].spec.allocationIPs}
            translatedNetwork: 10.200.0.10
            serviceEntry:
              protocol: TCP
              destinationPorts: "22"

Warning: the port did not reach NSX. VCF Automation’s API kept the serviceEntry (TCP 22), but the rule NSX realized had service: null: a DNAT of every port on 192.168.144.18 to the private address. Treat a NAT rule as a whole-address mapping. To publish one port, use a Virtual Machine Service of type LoadBalancer, which forwards only its ports and follows the VM’s address.

Group

kind: VPCNetworkSecurityGroup. A group of addresses, VMs or pods that firewall rules can name. Default wait: Realized.

  webGroup:
    type: CCI.VPC.Configuration
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCNetworkSecurityGroup
      configs:
        - generateName: web
          spec:
            vmSelectors:
              - labelSelector:
                  matchLabels: {tier: web}

Every VPC also has a group named default, made by NSX.

Gateway Firewall Policy

kind: VPCGatewayFirewallPolicy. Rules on the VPC’s gateway, for traffic entering and leaving the VPC. The distributed firewall inside the VPC is a separate thing.

Recipe, HTTPS from anywhere to the web group:

  gwPolicy:
    type: CCI.VPC.Configuration
    dependsOn: [attach]
    properties:
      vpc: ${resource.vpc.id}
      apiVersion: vpc.nsx.vmware.com/v1alpha1
      kind: VPCGatewayFirewallPolicy
      configs:
        - generateName: web-in
          spec:
            stateful: true
            rules:
              - name: https-in
                action: Allow
                direction: In
                from:
                  - ipAddress: 0.0.0.0/0
                to:
                  - groupName: ${resource.webGroup.configs[0].name}
                services:
                  - networkServiceName: ":HTTPS"

Gotchas

• from is required, whatever the field’s description says: without it, spec.rules[0].from: Required value. Write 0.0.0.0/0 for any source.
• Name a service rather than a port set. A rule that lists only an l4PortSet gets networkServiceName: Any added by the API, and NSX realizes it as services ANY beside the raw TCP 443 entry. With networkServiceName: ":HTTPS" NSX holds exactly /infra/services/HTTPS. The API lists 415 services, all with a leading colon (:DNS, :HTTPS, :SSH); without the colon it refuses: Network service name must start with a colon (:), such as :HTTP.
• groupName takes the group’s full name, <vpc>:<generateName>, which configs[0].name supplies.
• The gateway firewall has to be active in the VPC’s security profile for any of this to be enforced.

Supervisor Resource

type: CCI.Supervisor.Resource. Any Kubernetes object in the namespace, described by manifest. Every workload item that follows is this type with apiVersion and kind filled in, so everything here applies to them.

Recipe, a kind the palette doesn’t have. Our labs carry three VLANs over one trunk subnet with binding maps:

  bmMgmt:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: crd.nsx.vmware.com/v1alpha1
        kind: SubnetConnectionBindingMap
        metadata: {name: bm-mgmt}
        spec: {subnetName: sn-mgmt, targetSubnetName: sn-trunk, vlanTrafficTag: 1610}

On the 9.1 Supervisor the namespace’s API also offers, among others, VirtualMachineReplicaSet, VirtualMachineSnapshot, VirtualMachineImage, SubnetSet, ConfigMap and, with Avi, the Gateway API kinds.

Gotchas

• manifest can be a string as well as a map. Our generator writes one per host as a string, because a VM with optional sections is easier to build as text: manifest: "${...}" works as long as the expression returns valid YAML.
• Broadcom’s day-2 page warns that bindings don’t work for Supervisor Resources in day-2 operations; a day-2 action has to take the resource as an input.

Virtual Machine

CCI.Supervisor.Resource with apiVersion: vmoperator.vmware.com/v1alpha5, kind: VirtualMachine. A VM Service VM: built from a VM class (CPU, memory, devices) and an image, and configured on first boot by cloud-init, Sysprep, LinuxPrep or vApp properties.

The most used fields; the complete list of 266 follows.

Minimal:

  vm1:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha5
        kind: VirtualMachine
        metadata:
          name: web-01
          labels: {app: web}
        spec:
          className: best-effort-small
          imageName: ubuntu-24.04-server-cloudimg-amd64
          storageClass: vsan-default-storage-policy
      wait:
        conditions:
          - type: VirtualMachineGuestNetworkConfigSynced
            status: "True"

Recipes

• A Linux user with an SSH key and a password, inline cloud-init. The password is not a string here: passwd and hashed_passwd reference a key in a Secret, and a plain string fails with cannot restore struct from: string. The hash can come from Util.PasswordEntry:

          bootstrap:
            cloudInit:
              cloudConfig:
                users:
                  - name: ops
                    sudo: ALL=(ALL) NOPASSWD:ALL
                    lock_passwd: false
                    hashed_passwd:
                      name: web-pw          # a Secret in the namespace
                      key: ops-passwd       # holding ${resource.pw.sha512crypt}
                    ssh_authorized_keys:
                      - ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOkJfr8Q3cNq ops@example
                runcmd:
                  - [systemctl, enable, --now, ssh]
  

  We logged in through a load balancer as ops with that key; sudo needed no password and the shadow entry held the $6$ hash.

• Windows, or a long first-boot script: keep the whole cloud-config in a Secret and point rawCloudConfig at it. Our jump hosts run cloudbase-init this way:

          bootstrap:
            cloudInit:
              rawCloudConfig:
                name: jump-bootstrap     # the Secret
                key: user-data           # the key inside it
  

• A static address on a VPC subnet. With cloud-init the DNS servers go on the interface:

          network:
            hostName: dc01
            interfaces:
              - name: eth0
                network: {apiVersion: crd.nsx.vmware.com/v1alpha1, kind: Subnet, name: sn-mgmt}
                addresses: ["172.30.0.34/27"]
                gateway4: 172.30.0.33
                nameservers: [172.30.0.34]
          bootstrap:
            cloudInit:
              rawCloudConfig: {name: dc-bootstrap, key: user-data}
  

• An address on a subnet without choosing it: name the subnet and leave addresses out. VM Operator takes one from the subnet and configures the guest; ours got 172.30.0.2.

          network:
            interfaces:
              - name: eth0
                network: {apiVersion: crd.nsx.vmware.com/v1alpha1, kind: Subnet, name: sn-app}
  

• An extra data disk: a Persistent Volume Claim in the same blueprint, then the VM below. It arrived in the guest as sdb, 5 GiB, beside the image’s 10 GiB sda:

          volumes:
            - name: data
              persistentVolumeClaim:
                claimName: web-01-data
  

• An ISO in the CD-ROM, for an installer (our nested hosts boot the ESXi installer this way). guestID becomes mandatory:

          guestID: vmkernel9Guest
          hardware:
            cdrom:
              - name: cdrom0
                image: {kind: VirtualMachineImage, name: vmi-e400a813bbd5d52a5}
                connected: true
                allowGuestControl: true
  

• A bigger boot disk than the image’s: advanced.bootDiskCapacity: 80Gi. The guest still has to grow its partition.

• Keep VMs apart. Affinity rules only work for members of a Virtual Machine Group; on a VM without groupName the Supervisor refuses them (spec.groupName: Required value: when setting affinity). Our two web VMs with this rule landed on different hosts:

          groupName: web
          affinity:
            vmAntiAffinity:
              preferredDuringSchedulingPreferredDuringExecution:
                - labelSelector:
                    matchLabels: {app: web}
                  topologyKey: kubernetes.io/hostname
  

Status worth reading: status.network.primaryIP4 (after the wait above), status.powerState, status.nodeName (the ESXi host), status.zone, status.instanceUUID, status.biosUUID, status.hardwareVersion, and status.volumes[] with attached per disk.

Gotchas

• DNS settings depend on the bootstrap provider: spec.network.nameservers works only with LinuxPrep and Sysprep, the per-interface nameservers only with CloudInit and Sysprep, and a VM with no bootstrap can have neither. The Supervisor says which: nameservers is available only with the following bootstrap providers: ....
• promoteDisksMode defaults to Online: after a fast deploy from a linked clone, VM Operator copies the disks into full disks while the VM runs. For a large image that is real I/O; Disabled keeps the linked clone and deploys faster. Our Windows jump host was ready in 15.1 minutes with Disabled against 17.6 with the default. VMs with snapshots cannot promote online.
• The first deployment of a new image into a VPC can fail with an NSX 503638 error while the image is still being cached; a retry succeeds.
• Changing className resizes the VM; changing manifest in a new blueprint version recreates it.

Virtual Machine Group

CCI.Supervisor.Resource with apiVersion: vmoperator.vmware.com/v1alpha5, kind: VirtualMachineGroup. A set of VMs placed and powered as one: a boot order with delays between steps, and one power state for all of them.

Recipe, one VM before the next, thirty seconds apart:

  appGroup:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha5
        kind: VirtualMachineGroup
        metadata: {name: app}
        spec:
          bootOrder:
            - members: [{name: web-01}]
            - members: [{name: web-02}]
              powerOnDelay: 30s

Each member names the group in spec.groupName: app and depends on the group resource (dependsOn: [appGroup]), because the group is referenced only by name.

Status worth reading: status.members[] (each member’s power state and placement), status.conditions.

Gotchas

• A member of a later step stays off until every member of the earlier steps is on. When our first test’s web-01 failed to create, web-02 sat powered off for good.
• A VM in a group doesn’t place itself; the group places its members.

Virtual Machine Service

CCI.Supervisor.Resource with apiVersion: vmoperator.vmware.com/v1alpha5, kind: VirtualMachineService. A Kubernetes-style service in front of VMs, selected by label. With type: LoadBalancer, the VPC’s load balancer gives it an external address. That’s how a VM on a private subnet is reached from outside.

Recipe, RDP to a jump host, the only way into our labs:

  jumpAccess:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: vmoperator.vmware.com/v1alpha5
        kind: VirtualMachineService
        metadata: {name: jump-access}
        spec:
          type: LoadBalancer
          selector: {app: jump}
          ports:
            - {name: rdp, port: 3389, targetPort: 3389, protocol: TCP}
          loadBalancerSourceRanges: [10.0.0.0/8]

Status worth reading: status.loadBalancer.ingress[0].ip, the external address.

Gotchas

• LoadBalancer needs the VPC’s load balancer. VCF Automation waits for the address by itself, so in a VPC without one the request stays in progress until it times out. A VPC made by a blueprint never has one; see VPC.
• A service with several VMs behind it spreads connections across them: our SSH sessions alternated between the two web VMs.
• The palette writes v1alpha3; we use v1alpha5, the Supervisor’s stored version. Both are served.

Subnet

CCI.Supervisor.Resource with apiVersion: crd.nsx.vmware.com/v1alpha1, kind: Subnet. A subnet of the namespace’s VPC: a layer-2 segment with its own address range, for VMs that need a network of their own.

Minimal, our lab’s management subnet:

  snMgmt:
    type: CCI.Supervisor.Resource
    properties:
      context: ${resource.namespace.id}
      manifest:
        apiVersion: crd.nsx.vmware.com/v1alpha1
        kind: Subnet
        metadata: {name: sn-mgmt}
        spec: {accessMode: Private, ipv4SubnetSize: 32}

A VM joins it by name, in an interface: network: {apiVersion: crd.nsx.vmware.com/v1alpha1, kind: Subnet, name: sn-mgmt}.

Status worth reading: status.networkAddresses, status.gatewayAddresses, status.conditions (Realized).

Gotchas

• DHCP is off by default. VMs still get addresses: VM Operator takes one from the subnet and hands it to the guest through the bootstrap provider.
• Subnets are NSX objects of the VPC. After a deployment is deleted they can outlive it for a few minutes; wait until the VPC lists none before reusing the addresses.

Persistent Volume Claim

CCI.Supervisor.Resource with apiVersion: v1, kind: PersistentVolumeClaim. A disk from a storage class, for a VM’s volumes or a pod.