Check every item below before running the installer. The installer performs an automated prerequisite scan on its first screen, but fixing prerequisites after the fact is much slower than getting them right up front.

Installer Host

The machine on which you run vamctl.exe.

The installer host can be the same machine that runs VAM (for a single-node install on Hyper-V), or a separate management workstation (for VMware vSphere or remote Hyper-V deployments).

Podman and WSL 2

Every installation needs a working Podman machine, including a plain online install onto Hyper-V. The installer uses Podman to build the Talos boot images that provision the cluster nodes, and to stage offline bundles. Without it, the install cannot proceed past preparation.

The installer manages the machine for you: it creates one if none exists, sets it rootful with user-mode networking, sizes it, and starts it. You do not configure Podman by hand. What you must provide is the host support it depends on:

• WSL 2 installed, current, and the default version (wsl --status).
• Hardware virtualization enabled — WSL 2 needs it just as Hyper-V does.
• Enough headroom for the machine on top of Windows itself. On WSL 2 the machine's memory and CPU come from %UserProfile%\.wslconfig, not from Podman.

Cluster Nodes

VAM runs as a set of containerised services on a Kubernetes cluster. The nodes are the machines — physical or virtual — that make up that cluster. The requirements below are per node.

A cluster has two kinds of node:

• Control-plane nodes run Kubernetes itself (the API server, scheduler and the etcd datastore). For a highly-available cluster you need an odd number so etcd keeps quorum — the installer offers 1 (evaluation) or 3 (production).
• Worker nodes run the VAM services and hold the persistent storage for media, indexes and databases.

A typical resilient production layout is therefore 3 control-plane + 3 or more worker nodes. A single-node install collapses all roles onto one machine and is intended for evaluation and small productions.

Single-Node Evaluation

Multi-Node Production

Production sizing depends heavily on the size and volume of media your installation handles; the numbers above are a starting point. Ask your Vizrt representative for a sizing review before ordering hardware.

How the Installer Splits Disk per Node

You size each node with one number — its total disk. The installer divides that total into the two kinds of disk a node actually gets:

• a system disk (the Talos OS / ephemeral disk) that holds the container images plus every non-media persistent volume — OpenSearch, the Keycloak database, SurrealDB, RabbitMQ and friends all live here, because that storage class is backed by the node's own filesystem;
• one or more object-storage drives, separate disks that hold the S3 object store (media, proxies, artifacts).

The system portion is fixed by the installed software, so it does not grow with the total. Everything you add on top of it becomes asset storage — a bigger node means a bigger S3 store, not a bigger operating system.

The minimums come from the floors of the two parts: 80 GB of system disk and 50 GB per object-storage drive. At exactly 130 GB the split lands on both floors at once; above that the system disk holds at 120 GB (or at whatever TalosSystemDiskSize is set to in appsettings) and the rest goes to the asset store.

A control plane only stays small when the cluster actually has worker nodes — it is tainted and runs no application pods, and it receives no object-storage drive. In a single-node install there are no workers, so the control plane is schedulable, carries the whole stack and holds the asset store.

The wizard accepts anything at or above the minimums and warns — without blocking — below the recommended totals.

On Hyper-V these are dynamically expanding VHDX files: a 120 GB system disk only occupies as much host disk as it actually contains, so sizing generously up front costs nothing until the data exists. Sizing too small does cost you, because existing VHDs are never resized by a later run of the installer.

The cluster nodes are created and managed for you by the installer — they run Talos Linux, a minimal immutable Kubernetes OS, so you do not install or patch a node operating system by hand. The only exception is the bring-your-own Kubernetes option below, where you supply the cluster yourself.

Deployment Target

The installer can either provision the cluster nodes for you (on Hyper-V or VMware vSphere) or deploy into a Kubernetes cluster you already run. Pick the option that matches your infrastructure.

Hyper-V (Windows) — Single Host

The simplest option: the installer creates the Talos VMs on a single Windows Hyper-V host.

• Hyper-V role enabled on the host (the installer can enable it for you if you accept a reboot).
• A virtual switch already configured with network connectivity to the rest of your environment (internal or external vSwitch).
• Enough free RAM and disk on the host to satisfy the node sizing above — for a single-node evaluation, budget the full node spec plus headroom for the host OS.

Hyper-V Host Cluster (HA Production)

For a highly-available production deployment, run the VAM cluster across a failover cluster of at least 3 Hyper-V hosts, so the loss of one physical host does not take VAM down. Recommended per Hyper-V host:

For shared / cluster storage sizing on a Hyper-V failover cluster, ask your Vizrt representative — it depends on your media volume and retention.

VMware vSphere

The installer can also provision the Talos nodes on VMware vSphere.

• vCenter 7.0 or later (ESXi 6.7 Update 2+ / hardware version vmx-15), reachable from the installer host.
• A datacenter, host/cluster, datastore and a DHCP-enabled network / port group for the VMs.
• vCenter content libraries available (vCenter 6.5+).
• A vSphere account with permission to create VMs, attach storage and manage networking. The exact privilege set is in the VMware / vSphere deployment guide.
• A pre-uploaded Talos Linux OVA, or internet access from the installer host to download it.

See the VMware / vSphere deployment guide for the full walkthrough.

Bring Your Own Kubernetes Cluster

Instead of letting the installer create a cluster, you can point it at an existing Kubernetes cluster (on-prem or cloud). The installer then skips all VM / OS provisioning and only deploys the VAM Helm packages. That cluster must provide:

For the full prerequisites and the step-by-step install into your own cluster — storage (DirectPV), certificates (including AD Certificate Services), ingress and identity — see the Existing / native Kubernetes cluster guide.

Network

Enterprise identity & PKI (optional). Larger deployments often integrate with Microsoft Entra ID for sign-in (see Identity provider setup) and an internal certificate authority such as AD Certificate Services for TLS. Neither is required to install VAM — the installer can self-generate certificates and use the bundled Keycloak — but they are the recommended path for production.

Licensing

VAM requires a valid WIBU CodeMeter license. Two delivery options:

• Soft license container (CmActLicense file): sent by Vizrt as a .WibuCmRaU file. You load it via the installer's license step or directly through CodeMeter Control Center.
• Hardware dongle (CmDongle): plugged into a USB port on a host that the cluster can reach.

Have your license file or dongle available before starting the installer.

Identity Provider (for the Configuration Service)

VAM uses OpenID Connect (OIDC) for sign-in. Two options:

• Use the bundled Keycloak: the installer can deploy a Keycloak instance for you. Easiest for evaluations; nothing to prepare in advance.
• Use an existing OIDC provider: Microsoft Entra ID (Azure AD), Okta, Auth0, or your own Keycloak.

For an external provider, have ready before you start:

• The provider host / issuer URL (for Entra: https://login.microsoftonline.com plus your tenant ID).
• A client ID and client secret created for VAM.
• The redirect URIs to register, including https://<your-vam-host>/config/auth/callback and https://<your-vam-host>/auth/callback.
• For Entra specifically: the app roles defined (the vam for normal VAM usage and vam-admin for the cluster administration is mandatory) and admin consent granted.

Set up the external provider first. Completing it before you launch the installer turns the install into a single pass. Two guides cover it: OIDC Authentication Provider Configuration walks through the Entra ID app registrations step by step, and the Identity provider setup guide covers every supported provider plus the values the installer asks for.

You can change the identity provider later through Platform Settings, but it is easier to configure it during installation.

Before You Start the Installer

A short pre-flight checklist:

• [ ] Installer host meets the requirements above.
• [ ] You have chosen a deployment target (Hyper-V, VMware vSphere, or an existing Kubernetes cluster) and its hardware / hypervisor capacity is ready.
• [ ] Static IPs, DNS record and a reachable NTP source allocated.
• [ ] WIBU license available.
• [ ] You know which OIDC option you will use — and, for an external provider, you have completed the Identity provider setup and have the client ID, secret and (for Entra) tenant ID to hand.
• [ ] You have a backup destination in mind (file share, S3, or Azure Blob) — you will configure it after install.

Once these are in place, continue to Running the installer.