Platform teams leave a hypervisor console for the same reason they leave a cloud console: every change should be a diff. kcore treats virtual machines as resources. You write HCL, run terraform apply, and provider kcorehypervisor/kcore talks to the API over gRPC. It is a Go provider using the Terraform Plugin SDK, not a shell wrapper around SSH.
YAML is the other text path. kctl apply and kctl create read manifests. HCL and YAML are files. You can review them.
What provider 0.5.0 actually includes
Version 0.5.0 is the provider this site documents. It creates VMs, volumes, clusters, nodes, and the related resources the docs show in Terraform mode. It does not include everything the CLI can do.
- There is no Kubernetes cluster resource. Declare the cluster with kctl kubernetes and YAML.
- There is no PostgreSQL resource. Declare the database with CLI or YAML. It runs on the node from the NixOS package, one database per node, Unix socket in v1.
- There is no migrate or drain resource.
- kcore_vm storage_backend is filesystem, lvm, or zfs. Ceph on the VM is a kctl flag. A Ceph data disk is kcore_volume with storage class ceph.
- kcore_vm has no GPU attribute. Assign the card with CLI or YAML.
- Provider 0.5.0 does not inventory VMware or Proxmox. kcore-migrate writes guests.tf. After convert, set image_path and image_format on kcore_vm.
How to work
Put the provider in the repo next to the rest of your infrastructure. Pin version 0.5.0 until you have tested a newer one. Use YAML where the provider has no resource, and say so in the module README so the next person does not invent an attribute.
Terraform does not remove the product limits. Live migration still needs Ceph. A failed host update still boots the previous generation. Windows guests still run as guests, not as a managed SQL service. The text workflow comes after those limits. It does not erase them. The field lists are in the docs.
Questions: team@tacconiconsulting.com.