Terraform vSphere provider

The Terraform vSphere provider manages Kyvernon through the SOAP, REST and storage policy endpoints of the controller. The recorded verification used Terraform 1.17.1 with the provider hashicorp/vsphere 2.17.1. The provider is documented at registry.terraform.io.

Before you start

• Turn the compatibility endpoints on: Settings of the compatibility endpoints.
• Decide whether your configuration uses tags (vsphere_tag_category, vsphere_tag and the tags argument). The provider enables tags only when the endpoint reports the product name of the vendor's vCenter Server. In Kyvernon that needs the setting product_name, which is off by default. Everything else works with the default name.
• The controller uses a certificate that the provider does not know by default: set allow_unverified_ssl = true for a test, or trust the certificate on the machine that runs Terraform.

With the CLI

A configuration as it is written for vSphere. Names of the inventory objects are the ones the console shows:

terraform {
  required_providers {
    vsphere = {
      source  = "hashicorp/vsphere"
      version = "2.17.1"
    }
  }
}

provider "vsphere" {
  vsphere_server       = "controller.example.com:8443"
  user                 = var.vsphere_user
  password             = var.vsphere_password
  allow_unverified_ssl = true
}

data "vsphere_datacenter" "dc" {
  name = "Datacenter"
}

data "vsphere_compute_cluster" "cluster" {
  name          = "Cluster-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_datastore" "ds" {
  name          = "ds-local-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

data "vsphere_network" "net" {
  name          = "vm-net-01"
  datacenter_id = data.vsphere_datacenter.dc.id
}

resource "vsphere_virtual_machine" "web" {
  name                       = "prod-web-01"
  resource_pool_id           = data.vsphere_compute_cluster.cluster.resource_pool_id
  datastore_id               = data.vsphere_datastore.ds.id
  num_cpus                   = 2
  memory                     = 2048
  guest_id                   = "otherLinux64Guest"
  firmware                   = "efi"
  wait_for_guest_net_timeout = 0

  network_interface {
    network_id = data.vsphere_network.net.id
  }

  disk {
    label = "disk0"
    size  = 20
  }
}

terraform init
terraform plan
terraform apply

Set wait_for_guest_net_timeout = 0 when the guest has no guest agent running: the provider would otherwise wait for an address that the virtual machine cannot report. Without a reported address the provider plans a change of default_ip_address on every plan.

Verified resources

The recorded sequence is init, plan, apply, plan (no changes), apply of a change, plan (no changes) and destroy. The configuration used the data sources for datacenter, cluster, host, datastore, network and resource group, and the resources vsphere_folder, vsphere_virtual_machine (UEFI, a thin disk, a network adapter, an annotation), vsphere_virtual_machine_snapshot, vsphere_tag_category and vsphere_tag. The change added a vCPU, memory, a second disk, a grown disk, a tag and a snapshot. The details per step are in verified tools.

With the default product name, the steps init, plan and destroy pass. apply stops with the message that tags require the vendor's vCenter Server, because the configuration used tags. With product_name set, the complete sequence passed.

Known gaps

• Tags need product_name (see above).
• The adapter types vmxnet3, e1000e and e1000 are accepted and presented to the guest as virtio network adapters. The type sriov is refused.
• The provider's storage policy resources and vApps are not served. The service for storage policies answers its service content only.
• Settings without a meaning in Kyvernon, for example latency sensitivity or memory hot-add, are stored and read back, and have no effect.
• A change of CPU or memory of a running virtual machine powers the machine off first.

Related

• Compatibility overview
• Settings of the compatibility endpoints