Skip to main content
CID222 Docs

Install on Proxmox VE

Import the appliance OVA into Proxmox VE from the command line, size the guest, set the SMBIOS fields that make diagnostics recognise the platform, and reach the dashboard.

  • Version: 0.4
  • Role: admin_user
  • Type: task

Bring up a CID222 appliance on Proxmox VE. Proxmox does not import an OVA from its web interface the way vSphere does, so the appliance arrives through the shell: unpack the .ova, import the descriptor, attach the disk to a new guest, then size and start it.

What do I need?

Licence
Any
Role
admin_user

Prerequisites

  • You have the appliance .ova file and the .sha256 file supplied next to it.
  • You have root shell access to the Proxmox node, and a free virtual machine id.
  • The node has at least 32 GB of RAM, 8 CPU cores and 100 GB free on the target storage.
  • The bridge you will attach the appliance to serves DHCP.
  • You have read Requirements and sizing and Network prerequisites.

Note

Proxmox's own import tooling has changed across releases: recent versions accept an .ova file directly and offer an import view on directory storage, while older ones take only the extracted .ovf. The procedure below extracts first, which works on every version.

Import and start the appliance

Verify the download

On the Proxmox node, check the .ova against the .sha256 file supplied with it.

sha256sum -c cid222-appliance-v<version>.ova.sha256

The command prints OK. A mismatch means a corrupted download — fetch it again rather than importing it.

Unpack the archive

Extract the descriptor and the disk.

mkdir -p /var/tmp/cid-ova && tar -xf cid222-appliance-v<version>.ova -C /var/tmp/cid-ova
ls /var/tmp/cid-ova

The directory holds one .ovf descriptor, one .mf manifest and one .vmdk disk.

Import the descriptor

Import it into a free virtual machine id on your target storage.

qm importovf <vmid> /var/tmp/cid-ova/*.ovf <storage>

The command creates the guest and converts the disk, printing the transfer as it goes. On a large disk this takes several minutes.

Size the guest

Set memory and cores to your package's recommended profile.

qm set <vmid> --memory 65536 --cores 16

qm config <vmid> shows the new values. The imported defaults are the supported minimum — 32 GB and 8 processors — which is a floor rather than a comfortable size.

Attach the network

Attach the guest to a bridge that serves DHCP.

qm set <vmid> --net0 e1000,bridge=vmbr0

qm config <vmid> lists the adapter. The appliance guest also carries virtio drivers, so virtio works in place of e1000 if you prefer it.

Confirm the firmware is SeaBIOS

Open Hardware → BIOS for the guest and confirm it reads Default (SeaBIOS).

The appliance image is built and verified for BIOS firmware. A guest switched to UEFI does not boot.

Identify the platform to the appliance

Open Options → SMBIOS settings (type1) and set Manufacturer to a value containing the word proxmox — for example Proxmox.

The field is saved on the guest's configuration and takes effect at the next power-on.

Start the appliance and find its address

Start the guest and open its console.

The guest boots to a login prompt. Log in at the console and run ip a, or read the address from the guest's Summary panel once the guest agent reports it.

Open the dashboard

Browse to http://<appliance-ip>/.

The appliance redirects to the first-boot setup wizard, because it has no administrator yet.

Why the SMBIOS step matters

Proxmox is the one platform an appliance cannot recognise from inside the guest. A default Proxmox guest is indistinguishable from any other QEMU guest: the virtualisation probe reports kvm and the firmware tables report a QEMU vendor and a generic machine name, exactly as plain QEMU or libvirt would. Setting an SMBIOS type 1 field that names Proxmox is the only evidence there is, and it is what makes the appliance's diagnostics snapshot report the platform as Proxmox rather than as generic KVM.

Skipping it costs you nothing operationally. It costs a support engineer the ability to see which platform a snapshot came from without asking, because everything the probe read is preserved verbatim but reads as an ordinary QEMU guest.

Verify

  1. qm config <vmid> reports the memory, core count and adapter you set, and no EFI disk.
  2. http://<appliance-ip>/ loads and lands on the setup wizard rather than a login form.
  3. From a machine on the same network, curl -sS -o /dev/null -w '%{http_code}\n' http://<appliance-ip>/ returns 200.
  4. Where the appliance's diagnostics snapshot is available, it reports the platform as Proxmox rather than as generic KVM. If it reports KVM, the SMBIOS field was set after the last power-on — stop and start the guest, rather than rebooting from inside it. This step is worth doing whether or not you can read the snapshot back: the value is recorded on the guest and costs a support engineer nothing later.

If it fails

  • qm importovf rejects the descriptor → you pointed it at the .ova on a Proxmox version that takes only an extracted .ovf. Unpack it first, as in the second step.
  • The guest boots to a grub rescue prompt or hangs before the login prompt → the firmware was switched to UEFI. Set BIOS back to Default (SeaBIOS) and start it again.
  • The console shows a login prompt but ip a reports no IPv4 address → the bridge served no DHCP. Move the adapter to a bridge with DHCP, or install from the ISO using its manual-network boot entry — see Install from the ISO.
  • The page will not load and the console shows containers still starting → give it a few more minutes; a brief 502 during first boot is expected.

Next steps

Last updated on

On this page

Download PDF