Automated Proxmox installation: answer file and ISO

WZ-IT supports Proxmox setup with coordinated storage and networking. Automated installation is integrated into environment configuration and acceptance.

Automated Proxmox installation replaces host installer input with an answer.toml. It differs from guest cloud-init and subsequent configuration management (installation manual, cloud-init).

As of October 2026. Workflow based on vendor documentation and official installer source. Match the examples to the ISO version and target hardware before use. For a single host, install Proxmox describes the interactive workflow.

Contents

• 1. Define target host and answer source
• 2. Prepare the answer file
• 3. Validate the file and prepare the ISO
• 4. Check installation and first boot
• Errors and boundaries
• Sources

1. Define target host and answer source

Prepare an official Proxmox ISO supporting auto-install, proxmox-auto-install-assistant from the Proxmox package repositories and an inventory of target disks, management network, DNS and hostnames. Record checksum and target version in your installation record (installation).

The auto-install assistant offers these three modes. The example below uses the ISO variant.

With the partition variant, the installer looks for a partition labelled proxmox-ais (also PROXMOX-AIS) containing the file answer.toml; a different label is set with --partition-label when preparing the ISO. With HTTP, the URL comes from the ISO, from DHCP option 250 or from a DNS TXT record proxmox-auto-installer.<search domain>. The SHA-256 certificate fingerprint comes from the ISO, from DHCP option 251 or from the TXT record proxmox-auto-installer-cert-fingerprint.<search domain>. The installer sends JSON data about the target system via POST; the server can use it to select the matching answer file (automated installation). An arbitrary file server is not sufficient for this.

2. Prepare the answer file

Start with the minimal TOML file in the vendor repository. This example shows its structure with values to replace:

[global]
keyboard = "de"
country = "de"
fqdn = "pve01.example.invalid"
mailto = "[email protected]"
timezone = "Europe/Berlin"
root-password = "REPLACE_WITH_UNIQUE_SECRET"

[network]
source = "from-dhcp"

[disk-setup]
filesystem = "ext4"
disk-list = ["REPLACE_WITH_CONFIRMED_EMPTY_DISK"]

Do not boot this unchanged. FQDN, email, password and disk selection must match the target. The placeholder disk is deliberately not a valid target. DHCP is only an example for a prepared management network; the subsequent address must remain reliably reachable. Instead of a plaintext password the installer accepts root-password-hashed; the documentation shows a hash in yescrypt format ($y$…) for this.

The most important sections and keys according to the vendor documentation:

An example with a static address, a ZFS mirror and a disk filter. The address range 192.0.2.0/24 is reserved for documentation; replace all values:

[global]
keyboard = "de"
country = "de"
fqdn = "pve02.example.invalid"
mailto = "[email protected]"
timezone = "Europe/Berlin"
root-password-hashed = "REPLACE_WITH_HASH"
root-ssh-keys = ["REPLACE_WITH_PUBLIC_KEY"]

[network]
source = "from-answer"
cidr = "192.0.2.10/24"
gateway = "192.0.2.1"
dns = "192.0.2.53"
filter.ID_NET_NAME_MAC = "*REPLACE_WITH_MAC_SUFFIX"

[disk-setup]
filesystem = "zfs"
filter.ID_MODEL = "REPLACE_WITH_MODEL*"
filter-match = "any"

[disk-setup.zfs]
raid = "raid1"

With ZFS, raid1 means a mirror across the filtered disks. Filters select devices by udev properties: for disks for example DEVNAME, ID_SERIAL_SHORT, ID_WWN, ID_MODEL and ID_SERIAL, for network cards for example ID_NET_NAME and ID_NET_NAME_MAC. The wildcards * and ? and ranges such as [0-9] are allowed. With filter-match = "all" every condition must match, with any one is enough.

Installation overwrites selected target disks. Back up existing data and check disks and cabling against the inventory. Do not copy device names such as sda between machines without checking them. For filters and valid network fields, use the auto-install procedure for the selected ISO version; do not select other disks as a trial.

3. Validate the file and prepare the ISO

After adapting and protecting the answer file, run on the preparation machine, not as an installation command on a running production host:

proxmox-auto-install-assistant validate-answer answer.toml
proxmox-auto-install-assistant prepare-iso ./proxmox-ve.iso --fetch-from iso --answer-file ./answer.toml

Three further subcommands help with disk selection:

proxmox-auto-install-assistant device-info -t disk
proxmox-auto-install-assistant device-info -t network
proxmox-auto-install-assistant device-match disk ID_SERIAL='REPLACE_WITH_SERIAL*'

device-info shows the udev properties of the devices of the system it runs on. For filters they must therefore be determined on the target system or on identical hardware. device-match shows which devices a filter matches. inspect-iso examines a prepared ISO file; sensitive values stay hidden without --show-sensitive.

Syntax and options follow the assistant. Compare against the installed version's --help. The tool prints the generated ISO filename. Validation does not replace a target hardware check.

Treat the answer file and generated ISO as confidential. Keep credentials out of repositories and public downloads. For HTTP delivery, design host assignment, access and certificate verification separately; the ISO example does not configure an answer server.

4. Check installation and first boot

First verify the complete workflow, including disk selection, in a disposable test environment. Then boot from the prepared medium with confirmed inventory. Automatic boot is not subsequent confirmation of the installation target.

After reboot, check management access, FQDN, addresses, DNS, time, storage and boot without installation media. Repositories and updates follow the installation guide. Cluster joining and cluster networking require separate planning. The next layer is creating a VM.

Follow-up work can be automated at first boot: --on-first-boot embeds a script in the ISO, alternatively [first-boot] with source = "from-url" downloads one. ordering defines whether it runs before the network, when the network is up or after full startup. A [post-installation-webhook] reports the end of the installation to a URL. Treat scripts like the answer file: store them versioned, read them before use and do not embed credentials in plaintext.

Errors and boundaries

Proxmox setup by WZ-IT connects host installation with storage, networking and documentation. Installation alone does not define an operating model.

Sources

• Proxmox: installation manual
• Proxmox: auto-install assistant
• Proxmox: minimal answer file
• Proxmox: automated installation