Anatomy of a VM script

This page follows vm/ubuntu-vm.sh from the first line to the last. It is the script that uses the most engine helpers, so it shows the current way of doing each step. Where other scripts still do a step by hand, the difference is pointed out.

Everything here is Proxmox VE. The Incus scripts are much shorter and are covered at the end. The functions themselves are documented on the VM engine page.

The steps at a glanceCopy Anchor Link

1. Loading the VM engineCopy Anchor Link

COMMUNITY_SCRIPTS_URL="${COMMUNITY_SCRIPTS_URL:-https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main}"
source <(curl -fsSL "${COMMUNITY_SCRIPTS_CORE_URL:-https://raw.githubusercontent.com/community-scripts/core/main}/pve/vm-core.func")
load_functions

A VM script loads one file, pve/vm-core.func. That file pulls in host/validate.func and vm/common.func itself and turns on set -euo pipefail. vm/cloud-init.func is loaded later, only when Cloud-Init is used.

load_functions sets the colours, icons and STD, loads the telemetry functions and checks that the shell is Bash. It does not run any host check; the script does that itself in step 3.

pve/vm-core.func is also a dispatcher: on a host without pveversion but with a working incus, it loads incus/vm-core.func instead and returns.

2. Identity, traps and working directoryCopy Anchor Link

APP="Ubuntu"
APP_TYPE="vm"
NSAPP="ubuntu-vm"
GEN_MAC=02:$(openssl rand -hex 5 | awk '{print toupper($0)}' | sed 's/\(..\)/\1:/g; s/.$//')
RANDOM_UUID="$(cat /proc/sys/kernel/random/uuid)"
METHOD=""
var_os="ubuntu"
var_version="26.04"
THIN="discard=on,ssd=1,"
USE_CLOUD_INIT="no"

set -Eeo pipefail
shopt -s inherit_errexit
trap 'error_handler $LINENO "$BASH_COMMAND"' ERR
trap cleanup EXIT
trap 'post_update_to_api "failed" "130"' SIGINT
trap 'post_update_to_api "failed" "143"' SIGTERM
trap 'post_update_to_api "failed" "129"; exit 129' SIGHUP

TEMP_DIR=$(mktemp -d)
pushd "$TEMP_DIR" >/dev/null

error_handler reports the failed line and command, then calls cleanup_vmid, which stops and destroys the VM. cleanup runs on every exit: it leaves and removes TEMP_DIR and sends the final telemetry status if nobody did.

The image is downloaded to a cache, but all work on it happens in TEMP_DIR.

3. Host checks and toolsCopy Anchor Link

vm_preflight
vm_require_tools virt-customize

vm_preflight runs once, in this order:

vm_require_tools installs missing host tools with apt-get before anything is created. It knows jq, curl, pv, unzip, zstd, bzip2, gzip, openssl, wget, rsync, gunzip, xz, 7z, virt-customize, virt-resize, virt-filesystems and guestfish.

A script whose upstream publishes one architecture only says so before the checks. From vm/archlinux-vm.sh:

vm_require_arch amd64

A script that supports ARM hosts sets var_arm64="yes" (vm/docker-vm.sh, vm/pimox-haos-vm.sh) and builds its URLs with vm_arch_resolve.

4. Defaults and the wizardCopy Anchor Link

Every script defines two functions and hands them to vm_start_script:

function default_settings() {
  select_os "${VM_OS_VERSION:-}"
  VMID=$(get_valid_nextid)
  vm_apply_machine_type "q35"
  DISK_SIZE="7G"
  DISK_CACHE=""
  HN="ubuntu"
  CPU_TYPE=""
  CORE_COUNT="2"
  RAM_SIZE="2048"
  BRG="vmbr0"
  MAC="$GEN_MAC"
  VLAN=""
  MTU=""
  START_VM="yes"
  METHOD="default"
  # ... prints the summary
}

function advanced_settings() {
  METHOD="advanced"
  select_os
  vm_prompt_vmid "${VMID:-$(get_valid_nextid)}"
  vm_prompt_machine_type "q35"
  vm_prompt_disk_size "${DISK_SIZE:-7G}" "Set Disk Size in GiB (e.g., 10, 20)"
  vm_prompt_disk_cache "none"
  vm_prompt_hostname "ubuntu"
  vm_prompt_cpu_model "kvm64"
  vm_prompt_cpu_cores "2"
  vm_prompt_ram "2048"
  vm_prompt_bridge "vmbr0"
  vm_prompt_mac "$GEN_MAC"
  vm_prompt_vlan
  vm_prompt_mtu
  vm_prompt_keyboard
  vm_prompt_verbose "no"
  vm_prompt_start_vm "yes"

  if vm_confirm_advanced_settings "Ready to create a ${APP}?"; then
    echo -e "${CREATING}${BOLD}${DGN}Creating a ${APP} using the above advanced settings${CL}"
  else
    header_info
    echo -e "${ADVANCED}${BOLD}${RD}Using Advanced Settings${CL}"
    advanced_settings
  fi
}

vm_start_script "Use Default Settings?\n\nDefaults:\n• 2 CPU Cores\n• 2 GB RAM\n• 7 GB Disk" 13 58

vm_start_script runs vm_preflight (a no-op the second time), checks that the terminal can show dialogs, and asks Use Default Settings? with the buttons Yes and Advanced. Yes calls default_settings; Advanced calls advanced_settings. On the default path it then lowers CORE_COUNT to the number of host CPU threads if the script asked for more.

The variables are plain script variables, not var_*. Several of them are not values but ready-made fragments of the qm command line:

Every wizard questionCopy Anchor Link

The wizard is whatever advanced_settings calls, in that order. These are the engine's prompts. The default column is the function's own default; a script usually passes its own as the first argument.

Five more prompts exist in the engine for scripts that need them. No released or testing script calls them today:

Script-specific questions use vm_dialog directly. The Ubuntu release picker:

elif vm_dialog radiolist "UBUNTU VERSION" "Choose the Ubuntu release to install" --cancel-button Exit-Script 13 60 4 \
  "26.04" "Ubuntu 26.04 LTS (Resolute)" ON \
  "24.04" "Ubuntu 24.04 LTS (Noble)" OFF \
  "22.04" "Ubuntu 22.04 LTS (Jammy)" OFF; then
  var_version="$VM_DIALOG_RESULT"
else
  exit_script
fi

vm_dialog <box> <title> <whiptail arguments...> returns 0 for OK and 1 for Cancel, and puts the answer in VM_DIALOG_RESULT. Anything else ends the script: Esc as "User exited script", a dialog that could not be drawn with an error that names the terminal size.

On ARM hostsCopy Anchor Link

• vm_prompt_machine_type and vm_apply_machine_type always choose virt, whatever was passed. There is no dialog.
• vm_prompt_cpu_model leaves CPU_TYPE empty, so Proxmox VE uses the host CPU. All listed models are x86.

UnattendedCopy Anchor Link

With VM_UNATTENDED=1 no dialog is shown. vm_start_script calls default_settings, then applies these overrides:

Scripts add their own. Release pickers read VM_OS_VERSION.

VM_UNATTENDED=1 VM_OS_VERSION=24.04 VM_CORES=4 VM_RAM=4096 VM_DISK_SIZE=20G VM_STORAGE=local-lvm \
  bash -c "$(curl -fsSL https://raw.githubusercontent.com/community-scripts/ProxmoxVE/main/vm/ubuntu-vm.sh)"

The container variables (var_cpu, mode=, defaults files) have no effect on a Proxmox VE VM script.

5. The Cloud-Init questionCopy Anchor Link

VM_CLOUD_INIT="${VM_CLOUD_INIT:-yes}"
vm_prompt_cloud_init "ubuntu"
if [ "$USE_CLOUD_INIT" != "yes" ]; then
  msg_warn "Without Cloud-Init this Ubuntu image gets no network configuration or credentials; configure them in the guest yourself."
fi

vm_prompt_cloud_init [default user] asks three things: whether to enable Cloud-Init, the user name, and a password (twice; empty means one is generated). It sets USE_CLOUD_INIT and the CLOUDINIT_* variables.

On the Advanced path it continues with network mode (DHCP or static IP and gateway), DNS servers and SSH keys. A default-settings run gets DHCP, the DNS servers 1.1.1.1 8.8.8.8 and no SSH key.

Two things a script can set first:

• CLOUDINIT_REQUIRED=1 drops the yes/no question. vm/almalinux-vm.sh does this because its image has no console login without Cloud-Init.
• VM_CLOUD_INIT is the answer for unattended runs. Without it the answer is no, or yes when CLOUDINIT_REQUIRED=1.

vm/debian-vm.sh asks this question before vm_start_script, because the answer chooses the image (genericcloud or nocloud). vm_start_script then asks the Advanced-only part when the user picks Advanced.

6. Storage and disk namesCopy Anchor Link

post_to_api_vm
vm_select_storage "$HN"
vm_define_disk_references 2

post_to_api_vm sends the "installing" telemetry record; from here on a failure is reported.

vm_select_storage lists storages with images content. One storage is taken without asking, several open the Storage Pools dialog, a preset STORAGE is used as it is. No storage, or a preset name that does not exist, ends the script with exit code 119. It then sets the layout variables from the storage type:

vm_define_disk_references <count> builds the volume names Proxmox VE will use. With 2 on local-lvm and VM 105:

On dir storage DISK0_REF becomes local:105/vm-105-disk-0.qcow2.

Older scripts such as vm/debian-vm.sh still carry this case and the loop inline, with DISK_IMPORT="-format raw" instead of DISK_IMPORT_FORMAT.

7. Downloading the imageCopy Anchor Link

UBUNTU_ARCH="$(vm_arch_resolve amd64 arm64)"
URL="https://cloud-images.ubuntu.com/releases/server/${UBUNTU_CODENAME}/release/ubuntu-${var_version}-server-cloudimg-${UBUNTU_ARCH}.img"
CACHE_FILE="$(vm_image_cache_path "$URL")"
vm_fetch_image "$URL" "$CACHE_FILE" --cache --min-bytes $((100 * 1024 * 1024)) || exit 115
FILE="$(basename "$CACHE_FILE")"
cp -f "$CACHE_FILE" "$FILE"

• vm_arch_resolve <amd64 value> <arm64 value> prints the value for the host, so the URL is never hardcoded to one architecture.
• vm_image_cache_path returns /var/lib/vz/template/cache/<file name> (VM_IMAGE_CACHE_DIR overrides the directory).
• vm_fetch_image downloads into <target>.part, checks it, and only then renames it. With --cache, an existing file is verified and reused.
• The script then works on a copy in TEMP_DIR. The next step writes a hostname and a machine-id into the image; doing that to the cached file would hand them to every later VM.

vm_fetch_image options:

Without a checksum option, the vendor's own list is used when the URL is on cloud.debian.org, cloud-images.ubuntu.com, download.truenas.com, downloads.openwrt.org, download.freebsd.org (VM images) or mirror.turnkeylinux.org.

When a cached file no longer matches the upstream checksum, an Image Cache dialog offers Download or Keep cached. Unattended runs download the new one.

Finding the URL is the script's job. Three helpers cover the common cases:

# vm/zimaos-vm.sh: an asset of the latest GitHub release
vm_release_asset github IceWhaleTech/ZimaOS 'zimaos-x86_64-.*_installer\.iso$'
URL="$VM_RELEASE_URL"
vm_fetch_image "$URL" "$CACHE_FILE" --cache --min-bytes "$MIN_ISO_BYTES" --sha256 "$VM_RELEASE_SHA256" || exit 115

# vm/openwrt-vm.sh: the newest version named on a page
vm_latest_from_index "https://downloads.openwrt.org/.versions.json" '"stable_version": *"\K[0-9]+\.[0-9]+\.[0-9]+' || exit 115
var_version="$VM_INDEX_LATEST"

# vm/haos-vm.sh: unpack a compressed image; the result is in VM_IMAGE_FILE
vm_extract_image "$CACHE_FILE" || exit 115

Installer ISOsCopy Anchor Link

Scripts that boot an installer put the ISO on an ISO storage instead of the image cache. From vm/archlinux-vm.sh:

vm_select_iso_storage "$FILENAME" "$HN"
CACHE_FILE="$ISO_PATH"
vm_fetch_image "$URL" "$CACHE_FILE" --cache --min-bytes $((100 * 1024 * 1024)) || exit 115

vm_select_iso_storage <file.iso> [hostname] picks an active storage with iso content (the disk storage if it qualifies, otherwise the only one, or a dialog) and sets ISO_STORAGE, ISO_VOLUME and ISO_PATH. The VM then gets -cdrom "$ISO_VOLUME".

8. Preparing and converting the imageCopy Anchor Link

vm_prepare_cloud_image "$FILE" "$HN" || true
if [[ "$USE_CLOUD_INIT" != "yes" ]]; then
  vm_expand_image "$FILE" "$DISK_SIZE"
fi

vm_prepare_cloud_image <image> [hostname] installs libguestfs-tools on the host if needed and then changes the image offline with virt-customize:

1. sets the hostname;
2. empties /etc/machine-id, so two VMs from one image do not share a DHCP lease;
3. allows root and password login in sshd_config;
4. sets the host's time zone and keyboard layout;
5. enables a getty on tty1 and ttyS0, adds root autologin when the image has no cloud-init, and adds console=tty1 to the kernel command line;
6. installs and enables qemu-guest-agent.

A step that fails is listed by name; the function still returns 0. It returns 1 only when virt-customize is not available, and then the image is imported unmodified. That is why scripts write || true after it.

vm_expand_image <image> <size> grows the root partition and filesystem inside the image with virt-resize. It returns 1 when it could not, which is why debian-vm.sh and docker-vm.sh call it with || true. It is needed only without Cloud-Init: qm resize grows the block device, and in a Cloud-Init image growpart then grows the partition on first boot. Without Cloud-Init nothing would.

Script-specific changes use vm_customize, which returns the failure so the script can react. From vm/unifi-os-server-vm.sh:

vm_customize "UniFi OS installer" "$FILE" \
  --upload "unifi-os-server.bin:/opt/unifi-os-server.bin" \
  --chmod 0755:/opt/unifi-os-server.bin \
  --run-command "systemctl enable ssh" || exit 1

vm_firstboot_unit "$FILE" "unifi-os-firstboot" "$FIRSTBOOT_SCRIPT" \
  --description "UniFi OS Server First Boot Installer" \
  --after qemu-guest-agent.service \
  --requires-path /opt/unifi-os-server.bin \
  --cloud-init yes || exit 1

vm_firstboot_unit uploads a script and a oneshot systemd unit that runs it once on first boot. This is how a VM script installs something that cannot be installed offline.

Format conversionCopy Anchor Link

vm_import_disk passes --format "$DISK_IMPORT_FORMAT" and Proxmox VE converts during the import, so ubuntu-vm.sh has no conversion step. Some scripts convert first. From vm/fedora-vm.sh:

if [[ "$DISK_IMPORT_FORMAT" == "raw" ]]; then
  msg_info "Converting image to raw format"
  RAW_FILE=$(mktemp --suffix=.raw)
  qemu-img convert -f qcow2 -O raw "$WORK_FILE" "$RAW_FILE"
  rm -f "$WORK_FILE"
  WORK_FILE="$RAW_FILE"
  msg_ok "Converted image to raw format"
fi

9. Creating the VMCopy Anchor Link

vm_claim_vmid
msg_info "Creating a ${APP}"
qm create $VMID -agent 1${MACHINE} -tablet 0 -bios ovmf${CPU_TYPE} -cores $CORE_COUNT -memory $RAM_SIZE \
  -name $HN -tags community-script -net0 virtio,bridge=$BRG,macaddr=$MAC$VLAN$MTU -onboot 1 -ostype l26 -scsihw virtio-scsi-pci
vm_mark_created

qm create is written out in every script; there is no wrapper. The engine only supplies the fragments. With the defaults on an amd64 host this expands to:

qm create 105 -agent 1 -machine q35 -tablet 0 -bios ovmf -cores 2 -memory 2048 \
  -name ubuntu -tags community-script -net0 virtio,bridge=vmbr0,macaddr=02:AB:CD:EF:01:23 -onboot 1 -ostype l26 -scsihw virtio-scsi-pci

Two calls frame it:

• vm_claim_vmid checks the ID again. It was chosen before the download, and another run may have taken it since. An automatically chosen ID moves to the next free one, and the disk names from step 6 are rebuilt. An ID typed in the wizard ends the script with exit code 205.
• vm_mark_created switches the error handling: from here on a failure leaves the VM in place. It also sets the VM's keyboard layout.

10. EFI disk, disk import and qm setCopy Anchor Link

vm_alloc_efi_disk "$DISK0"
vm_import_disk "$VMID" "$FILE" "$STORAGE" "$DISK_IMPORT_FORMAT"
qm set $VMID \
  -efidisk0 ${DISK0_REF}${FORMAT} \
  -scsi0 ${VM_IMPORTED_DISK},${DISK_CACHE}${THIN}size=${DISK_SIZE} \
  -boot order=scsi0 \
  -serial0 socket >/dev/null

EFI diskCopy Anchor Link

vm_alloc_efi_disk [volume name] runs pvesm alloc "$STORAGE" "$VMID" "$DISK0" <size>. The size is 4M on amd64 (OVMF) and 64M on arm64 (AAVMF). qm set -efidisk0 then writes the firmware variables into that volume.

Scripts use one of three forms:

SeaBIOS VMs have no EFI disk.

Importing the diskCopy Anchor Link

vm_import_disk <vmid> <image> <storage> [format] flushes the image to disk, runs qm disk import (or qm importdisk where that subcommand is missing) and stores the volume Proxmox VE created in VM_IMPORTED_DISK. The script attaches that volume, not a guessed name.

Older scripts call qm importdisk themselves and attach ${DISK1_REF}:

# vm/debian-vm.sh
qm importdisk $VMID ${FILE} $STORAGE ${DISK_IMPORT:-} 1>&/dev/null

Installer scripts import nothing. They create an empty disk in qm create. From vm/zimaos-vm.sh:

-scsi0 ${STORAGE}:${DISK_SIZE%G},${DISK_CACHE}${THIN%,} \
-cdrom "$ISO_VOLUME" -boot order='scsi0;ide2' -vga std -serial0 socket

What qm set attachesCopy Anchor Link

No Cloud-Init drive is attached here. vm_provision adds it in step 12, and attaching it twice fails.

TPMCopy Anchor Link

The engine has no TPM helper on Proxmox VE. almalinux-vm.sh, alpine-vm.sh and fedora-vm.sh add a TPM 2.0 state disk themselves, as a third volume. From vm/fedora-vm.sh:

vm_define_disk_references 3
# ...
vm_alloc_efi_disk "$DISK0"
pvesm alloc "$STORAGE" "$VMID" "$DISK2" 4M 1>&/dev/null
qm importdisk "$VMID" "$WORK_FILE" "$STORAGE" -format "$DISK_IMPORT_FORMAT" 1>&/dev/null
qm set "$VMID" \
  -efidisk0 "${DISK0_REF}${FORMAT:-}" \
  -scsi0 "${DISK1_REF}",${DISK_CACHE}${THIN}size="${DISK_SIZE}" \
  -tpmstate0 "${DISK2_REF}",version=v2.0 \
  -boot order=scsi0 \
  -serial0 socket >/dev/null

11. Description panel and disk resizeCopy Anchor Link

set_description
vm_resize_disk

set_description writes the HTML panel shown under Notes in the Proxmox VE web interface: the Community-Scripts logo, APP as the title, a donation badge, a link to https://community-scripts.org/scripts/<slug>, and links to GitHub, Discussions and Issues. The slug is SCRIPT_SLUG, else NSAPP, else APP, in lower case without spaces.

vm_resize_disk [disk] [size] runs qm resize "$VMID" scsi0 "$DISK_SIZE". The imported image is as large as the vendor made it; this grows the block device to what the user asked for. qm refuses to shrink, so a failure is only a warning.

12. Cloud-Init provisioningCopy Anchor Link

vm_provision "$VMID"
if [[ "$USE_CLOUD_INIT" == "yes" && -n "${CLOUDINIT_SSH_KEYS:-}" ]]; then
  $STD qm set "$VMID" --sshkeys "$CLOUDINIT_SSH_KEYS"
fi
if [ "$USE_CLOUD_INIT" = "yes" ]; then
  if [[ "${CLOUDINIT_NETWORK_MODE:-dhcp}" == "static" ]]; then
    setup_cloud_init_network_no_rename \
      "$VMID" \
      "$MAC" \
      "$CLOUDINIT_IP" \
      "$CLOUDINIT_GW" \
      "${CLOUDINIT_DNS:-${CLOUDINIT_DNS_SERVERS:-1.1.1.1 8.8.8.8}}" \
      "${CLOUDINIT_SEARCH_DOMAIN:-local}"
  fi
fi

vm_provision <vmid> does nothing when USE_CLOUD_INIT is not yes. Otherwise it loads vm/cloud-init.func and calls setup_cloud_init with the answers from step 5. That attaches the Cloud-Init drive and sets user, password, SSH keys, IP configuration, DNS and search domain. The credentials are written to /tmp/<hostname>-<vmid>-cloud-init-credentials.txt.

If the helpers cannot be loaded, vm_provision warns and returns 1. The VM exists by then, so scripts either ignore that (vm_provision "$VMID" || true in fedora-vm.sh) or report it (docker-vm.sh).

The static-IP block is specific to ubuntu-vm.sh and debian-vm.sh. It replaces Proxmox VE's generated network configuration with a snippet that matches the NIC by MAC address. See the network snippet.

13. Start, summary and finishCopy Anchor Link

vm_start_vm "$APP"
vm_wait_for_ip 120 || true

if [ "$USE_CLOUD_INIT" = "yes" ] && declare -f display_cloud_init_info >/dev/null 2>&1; then
  display_cloud_init_info "$VMID" "$HN"
fi

vm_print_summary \
  "Ubuntu Release=${var_version} (${UBUNTU_CODENAME})" \
  "Cloud-Init=${USE_CLOUD_INIT}"

vm_finish

• vm_start_vm [label] runs qm start when START_VM is yes.
• vm_wait_for_ip [seconds] asks the guest agent for the address of the NIC with the VM's MAC and stores it in VM_IP. It returns non-zero when the VM was not started or no address appeared, so it is followed by || true.
• display_cloud_init_info prints user, password and the credentials file.
• vm_print_summary ["Label=value"...] prints VM ID, hostname, resources, state and IP address, then the extra rows. Empty values are skipped.
• vm_next_steps <step>... prints a numbered list.
• vm_finish [message] sends the "done" telemetry status and prints the closing line.

Older scripts start the VM with $STD qm start $VMID and call post_update_to_api "done" "none" themselves.

What happens when a step failsCopy Anchor Link

Run a script with VERBOSE=yes, or pick Verbose in the wizard, to see command output instead of the spinner. The log of a run is /tmp/cs-vm-<pid>.log.

Scripts use these exit codes for their own checks:

The codes the engine itself uses are listed under exit codes.

Helper functions a VM script may callCopy Anchor Link

Signatures as defined in pve/vm-core.func and vm/common.func. The wizard prompts are in the table above.

Setup and checksCopy Anchor Link

Machine settingsCopy Anchor Link

ImagesCopy Anchor Link

Storage and disksCopy Anchor Link

After creationCopy Anchor Link

The same VM on IncusCopy Anchor Link

vm/ubuntu-vm.sh in the Incus repository is not a port. It loads incus/vm-core.func, sets var_image, and after the wizard makes one call:

var_image="${var_image:-images:ubuntu/26.04}"
# ...
vm_start_script
incus_vm_create "$var_image" "$HN" "$DISK_SIZE"

incus_vm_create <image> <name> <disk-size> replaces steps 6 to 13. It resolves the image, runs incus init --vm, applies every setting, writes the Cloud-Init configuration into the instance config, starts the VM and waits for the agent and an address.

There is no image download, no virt-customize, no EFI disk, no import and no machine type. A script that needs a vendor image passes a file instead of an image alias. From the Incus vm/haos-vm.sh:

vm_fetch_image "$URL" "$CACHE_FILE" --cache --verify-xz --min-bytes $((5 * 1024 * 1024)) || exit 115
xz -dc "$CACHE_FILE" >"$IMAGE_FILE"
incus_vm_create "$IMAGE_FILE" "$HN" "$DISK_SIZE"

The Incus wizard asks different questions (Secure Boot, virtual TPM, GPU, USB and PCI passthrough, snapshots, profiles). They are listed on the engine page.

Before you submit a VM scriptCopy Anchor Link

• Start from a current script of the same kind: ubuntu-vm.sh for a cloud image, zimaos-vm.sh for an installer ISO, unifi-os-server-vm.sh for an application installed on first boot.
• Use vm_arch_resolve in URLs, or state the architecture with vm_require_arch.
• Download with vm_fetch_image --cache and a --min-bytes that a real image clears easily. Pass a checksum when the upstream publishes one.
• Work on a copy of the cached file.
• Call vm_claim_vmid before qm create and vm_mark_created after it.
• Test on file storage (dir) and on block storage (LVM-thin or ZFS). The volume names and the import format differ.
• Test the default path, the Advanced path and VM_UNATTENDED=1.