Stashboard V8.4 finally ships a real create Proxmox VM web UI form, and V8.5 makes the VM Config tab writable — so a full QEMU guest can be born, tuned, and grown without you ever opening the Proxmox VE console. Until these two releases the create Proxmox VM web UI story stopped at containers: LXC got its own guarded form back in V6.13.1, while virtual machines stayed stubbornly read-only. This guide covers both halves — what the New VM form actually provisions on the node, what the Config tab can change afterwards, and the two guardrails (a changed-keys-only Save and a grow-only disk resize) that keep an edit from turning into an outage. 🧱
Where the create Proxmox VM web UI form lives
Open a Proxmox host in Stashboard, click the host actions menu, and New VM now sits right beside New LXC. That is the entire entry point for the create Proxmox VM web UI flow — same menu, same modal shell, same permission model you already learned when you started to create Proxmox LXC from the web UI.
The create Proxmox VM web UI dialog reuses the Docker container modal shell Stashboard already uses elsewhere, so the layout will feel familiar the first time you open it. More importantly, the client-side guards in that form mirror the server-side validator one for one. A bad VMID, a missing storage, or a memory value the API would reject gets caught in the browser, before a request ever leaves your machine.
One rename to expect: Settings → Create LXC is now Settings → Create guest, because the same switch governs both container and VM creation. If you went looking for the old label and could not find it, that is why.
⚠️ Both gates are still off by default
Nothing about the create Proxmox VM web UI feature is enabled out of the box. It reuses exactly the same double gate as LXC create:
Stashboard:AllowProxmoxCreate— the instance-wide master switch. Off, and no guest-creation UI appears anywhere, for anyone.- Per-host
AllowCreate— an opt-in flag on each individual Proxmox host. Off, and that particular host refuses creation even when the master switch is on.
⚠️ Both must be on before any create Proxmox VM web UI action is possible. This is deliberate: creation is the one Proxmox action that consumes real storage and real VMIDs on your cluster, so it stays behind two separate, explicit decisions. Turn on the per-host flag only for hosts you actually want to provision from — a backup node or a borrowed cluster member is a good candidate to leave permanently off.
The New VM form and what submit actually provisions
The create Proxmox VM web UI form is short on purpose. It asks for a VMID and name, CPU (cores and sockets), memory, the storage that should hold the system disk and its size, a bridge for networking, a BIOS/machine pair, an OS type hint, and — optionally — an install ISO.
That ISO list is not something you type. Stashboard performs ISO discovery across the node: it walks every iso-capable storage on that node and lists the installable iso images it finds, so you pick from what genuinely exists rather than guessing at a volume ID. If you have Debian, Windows, and a rescue image scattered across local and a shared NFS mount, they all show up in the same dropdown.
Submit is where the create Proxmox VM web UI flow stops being a form and becomes hardware. It sends a POST /nodes/{node}/qemu that provisions a coherent, boring, correct machine:
scsi0— the system disk, attached to avirtio-scsi-pcicontroller.net0— avirtioNIC on the bridge you chose.bios+machine— set together, as a matched pair.ostype— the hint Proxmox uses to tune defaults for the guest OS.ide2— the install CD-ROM, only if you picked an ISO.boot— an order that actually boots the thing you just built.
If you select OVMF (UEFI) as the BIOS, Stashboard also auto-provisions an efidisk0 on the same storage as the system disk. That single detail removes the most common first-boot failure in hand-rolled UEFI VMs: a machine that has firmware but nowhere to keep its variables.
Then it waits. The API’s 200 OK only means “task accepted”, so the create Proxmox VM web UI flow takes the returned task UPID and polls it until Proxmox reports a real terminal state. You get success or a genuine failure reason — never a green toast over a VM that quietly never materialised. It is the same honesty model used across the rest of the Proxmox management dashboard.
The Config tab is finally writable
The VM Config tab has existed since V6.14, but it was strictly read-only: a nice inventory of what the machine looked like, and nothing you could do about it. V8.5 turns it into an editor, which is where the create Proxmox VM web UI feature stops being a one-shot provisioner and becomes real day-two management.
What you can edit directly:
- Identity — name, description, tags.
- CPU — cores and sockets.
- Memory — the assigned amount plus a balloon minimum.
- Boot behaviour —
onboot(start with the node) and boot order. - OS hint —
ostype. - QEMU guest agent — a straight toggle.
- Networking — structured
net<n>add, update, and remove, handled through a QEMU net codec. This matters because a VM NIC is not shaped like an LXC one: its first token is the device model, and that token is what carries the MAC address. The codec parses and re-emits that correctly instead of mangling your NIC into a new MAC on every save. ide2— swap or eject the CD-ROM without touching the console. Ideal for pulling the installer out once an OS install finishes.
If you have already used the LXC config editor, the interaction model is identical — this is simply the VM half of the same idea, and it is what turns a create Proxmox VM web UI form into an actual management surface.
Changed-keys-only Save: why an edit can’t wreck a VM
This is the guardrail that makes editing safe enough to hand to a web form at all, and it is the single most important thing to understand about the create Proxmox VM web UI editor.
Every field in the editor follows a “null means leave untouched” merge rule. A field you did not deliberately change is not “the value I read a minute ago” — it is absent, and absent fields are never transmitted. So there is no read-modify-write race where a value you never looked at gets silently rewritten with a stale copy.
When you press Save, exactly once, Stashboard issues a single PUT /nodes/{node}/qemu/{vmid}/config carrying only the keys that actually changed, plus one consolidated delete= list for the keys you removed. One request, one atomic intent, one audit entry. Nothing else in the create Proxmox VM web UI stack is allowed to widen that payload behind your back.
There is one deliberate exception worth knowing about: disk flags. discard, SSD, and cache are re-emitted on Save rather than omitted, because they live inside the same disk string as the rest of the disk definition and would otherwise be dropped when that string is rewritten. Everything else obeys the changed-keys-only rule strictly.
⚠️ Disks: grow-only resize, never shrink
Disk operations get their own, stricter treatment inside the create Proxmox VM web UI editor, because they are the operations that destroy data when they go wrong.
Resize is grow-only, structurally. Stashboard does not send an absolute target size that Proxmox could interpret as “make this disk smaller”. It computes the difference and sends a +NG increment. A shrink request cannot be expressed in that format, which means a shrink can never physically reach the host — not because of a validation check you might bypass, but because the wire format has no way to say it. ⚠️ If you genuinely need a smaller virtual disk, that remains a console-and-backup job, exactly as it should be.
move_disk relocates a disk to different storage and is task-polled just like a clone: Stashboard follows the UPID until Proxmox reports the move actually completed, then refreshes. Long moves on spinning storage report honestly instead of timing out into ambiguity.
Every edit lands in the audit trail
Nothing you do through the create Proxmox VM web UI happens anonymously. Every applied config edit, resize, and disk move writes a ProxmoxConfigAudits row. Each row records who did it, when, which host and node, which VMID, what kind of guest it was, what changed, and the result.
You read it in the same place as everything else: Audit page → Guest config tab. LXC config edits were retrofitted into that same trail, so containers and VMs now share one chronological record instead of two half-stories. If a VM starts behaving oddly a week after someone bumped its memory, the answer is one tab away — a habit worth pairing with LXC update monitoring.
How to verify your create Proxmox VM web UI setup works
Run this six-step pass on a throwaway VMID before you trust the create Proxmox VM web UI with anything real:
- Enable
Stashboard:AllowProxmoxCreate, then enableAllowCreateon one host under Settings → Create guest. - Open that host, choose New VM, and confirm the ISO dropdown lists images from your iso-capable storages. If it is empty, the storage is not marked for ISO content on that node.
- Create a small VM with OVMF (UEFI) selected. When it finishes, open the Config tab and confirm both
scsi0andefidisk0exist on the storage you picked. - Change only the description, then press Save. Check Audit → Guest config and confirm the entry lists that one key — not the whole config. That single check proves the changed-keys-only Save is doing what it claims.
- Grow the disk by 1 GB and watch the task poll to completion, then confirm the Config tab shows the new size.
- Eject
ide2and confirm the VM still boots from disk.
If step 4 shows more changed keys than you touched, stop and report it — that is the one behaviour the whole design depends on.
Bottom line: VM parity with LXC
Before V8.4, “manage Proxmox from a dashboard” quietly meant “manage containers from a dashboard, and open the console for VMs”. The create Proxmox VM web UI form closed the provisioning half of that gap, and the writable Config tab closed the day-two half. Creating, renaming, re-CPU-ing, re-networking, growing, and relocating a QEMU guest are now all things you do on the same screen where you watch your Docker stacks. 🚀
The reason that is safe is not the UI — it is the shape of the requests underneath. Only changed keys are transmitted. Only growth can be expressed. Every applied change is recorded with a name attached to it. Guardrails like those are what make a create Proxmox VM web UI worth using instead of merely faster to click, and they are why the create Proxmox VM web UI form and the Config editor were shipped as one story across two releases rather than as a single big-bang feature.
External references worth bookmarking: the Proxmox VE API viewer for the raw qemu endpoints, and the qm manual page for what each config key means on the host side.