Skip to content

Documentation

VMware vSphere

Provibr connects to a vCenter Server and manages the virtual machines in its inventory: order, clone, start, stop, suspend, remove, and read usage. All through the same agent, the same plans and the same audit trail as every other integration.

What this connects to

The integration talks to vCenter Server over its Web Services API. Everything the panel does (placement, cloning, guest configuration) runs through vCenter, so a cluster with DRS keeps deciding for itself which host a machine lands on.

A standalone ESXi host is not supported. It answers on the same API and the login even succeeds, but it has no clusters, no DRS and no resource pool to clone into. The agent checks what it is talking to and refuses a standalone host rather than failing at your first order.

How it differs from Proxmox

The model is the same: an agent, an integration, plans and templates. Four things behave differently, and they are the ones you will notice.

A machine is identified by its instance UUID and not by a number Provibr hands out. Everything you choose in the settings (datacentre, resource pool, network) is a vSphere object reference and not a name, because names in vSphere are only unique within their folder. And the “node” you see in the panel is the datacentre, not the ESXi host: the host changes with every vMotion, and a machine that appeared to move every hour would be unusable to reason about.

What you fill in

Four fields. Create a user of its own rather than reusing an administrator: vCenter has no revocable API token, so the role on the account is the limit.

  • The https address of vCenter, as you open it in the browser.
  • The user name including its domain, for example provibr@vsphere.local.
  • The password. It travels to your agent once and is never stored by Provibr.
  • The SHA-256 fingerprint of the certificate vCenter presents.
Give the account a role on the datacentre it should manage. Signing in works for any account vCenter knows, so an account without a role connects successfully and then sees nothing at all: no error, just an empty inventory. That is why the connection test reports how many datacentres it can see: zero means the credentials are fine and the role is missing.

The TLS fingerprint

Read it from any machine that can reach vCenter:

shell
openssl s_client -connect <host>:443 </dev/null 2>/dev/null | \
  openssl x509 -noout -fingerprint -sha256
Commands and terminal output are in English everywhere, in the panel and in these pages. One text, one truth: what you read here is literally what your host will print back.

This field is required. vCenter always serves a certificate signed by its own built-in CA, so there is no publicly trusted chain to fall back on and no unencrypted path either. With a fingerprint the agent trusts that one certificate instead of turning verification off.

Take the fingerprint of the machine certificate, not of the built-in CA. The vSphere Client lists both and they look alike. Pinning the CA gives you an integration that works immediately and stops months later, at the next certificate rotation.

Settings

Where new machines are placed. You pick these from what vCenter reports; there is nothing to type.

  • The datacentre new machines are created in.
  • The resource pool. On a DRS cluster this is the cluster's root pool and vSphere picks the host.
  • The port group the network adapter attaches to.
  • Optionally a fixed host. Leave it empty wherever DRS is on.
There is no datastore setting. A clone inherits the storage of its template, which is already somewhere it is allowed to be; choosing your own would let you point at a datastore the target host may not even see.

Templates

A template in vSphere is an ordinary virtual machine marked as one, in the same inventory. Link it to an operating system in your catalogue and orders for that system clone from it.

The list shows the datacentre next to the name, because two templates can share a name in different folders. Give the template VMware Tools and cloud-init; Provibr passes the guest configuration through the guestinfo channel, which works on any cloud image without extra requirements.

What you can do with a machine

Create from a template, start, stop, reset, shut down and reboot through VMware Tools, suspend and resume, read the status, and remove.

Not yet: adding or removing disks and network adapters, and reinstalling. Reinstalling in vSphere means cloning again, and there is no command that rebuilds the same machine in place. Per-machine firewalling is not part of vSphere at all: that is NSX, a separate product.

Networking

A new machine gets one adapter on the port group from the settings, and its address from your IPAM if the plan has a pool attached.

Distributed port groups are supported and are the normal case. They attach differently from classic networks (by the UUID of their switch plus their own key), and the agent works that out from the object itself, so nothing about it is yours to configure.

Importing what is already there

Machines that exist in vCenter outside Provibr can be imported from the integration page: tick the ones you want and they appear as servers, with their datacentre, state and specs.