VM lifecycle

Snapshots

Creating a VM snapshot can optionally include the VM’s live memory state, but only for actual VMs; a container has no memory state to snapshot, so that option is refused for container targets rather than silently ignored. Rolling back to a snapshot needs the VM’s name typed as confirmation, since it discards everything since that snapshot. Deleting a snapshot needs no confirmation: it doesn’t touch the guest or its disk, only the snapshot itself.

Creating and cloning

New VMs go through a five-step wizard (target host, OS, resources, network, then a final confirm), and get sensible defaults matching what the Proxmox UI itself would choose (a modern SCSI controller and a virtio NIC), rather than exposing every raw Proxmox parameter. If you don’t pick a VM ID yourself, Proxploy asks the cluster for the next free one. Cloning follows the same “pick a target, confirm” shape.

VM options

From a VM’s detail panel, the Options tab shows the VM’s current PVE configuration: name, onboot, boot order, OS type, QEMU agent, and other settings. You can edit any of these directly; the changes are applied immediately through the Proxmox API, not queued as a job. Only the options you explicitly change are sent; everything else is left alone.

Some options are restricted on the node that hosts Proxploy itself (the “self host”) to prevent an operator from accidentally rendering Proxploy unreachable.

Deleting a VM

Deleting a VM is the most destructive action in Proxploy, and it’s gated accordingly: it needs the owner role, above what everyday lifecycle actions require, and three checks run in order before anything is deleted: refusing a self-targeted delete, refusing a running guest, and requiring the VM’s name typed as confirmation. Every refusal is logged to the audit trail before the request is even rejected, so there’s a record of the attempt whether or not it succeeded.