Rules for Use of Proxmox

These rules apply to virtual machines running on Zenon's Proxmox infrastructure. They exist to ensure:

• Efficient and fair distribution of resources
• Stability and performance in the cluster
• Good organization and oversight of virtual machines
• Predictable operations and troubleshooting

Policy Requirements

1. Storage Limits

Default maximum disk size depends on the storage type (see rule 6 for how to split disks by type):

• HDD (high-capacity storage): 1 TB by default. Hard-blocked at 125 IOPS in Proxmox; Zenon's Grafana monitoring warns at 100 IOPS.
• SSD (high-I/O storage): 50 GB by default, up to 100 GB without requiring an exception. No IOPS limit or warning currently in place.

This applies to the sum of all disks of that type for a VM — splitting into multiple disks to circumvent the limit is not permitted.

2. Mandatory QEMU Guest Agent

QEMU Guest Agent must be installed and running on all virtual machines, before the VM goes into production.

• Linux: install the qemu-guest-agent package
• Windows: install the agent from the VirtIO ISO

# Install agent
sudo apt-get install qemu-guest-agent  # Debian/Ubuntu
sudo yum install qemu-guest-agent      # RHEL/CentOS

# Start and enable service
sudo systemctl start qemu-guest-agent
sudo systemctl enable qemu-guest-agent

# Verify agent is running
sudo systemctl status qemu-guest-agent

Verify in the Proxmox UI that the agent is connected (green checkmark next to the VM's IP addresses).

The guest agent enables safe shutdowns and restarts, better snapshot synchronization, and correct IP reporting. VMs without a running QEMU Guest Agent will be shut down without warning when Zenon requires it — this may result in data loss or an inconsistent state.

3. Pool Organization

All VMs must be assigned to the Proxmox Pool for the product area they belong to. This must currently be done manually when creating the VM, and gives visibility into resource usage and ownership per product area.

VMs found without a pool are added to the correct pool if it's obvious which one that is; otherwise the owner is contacted if they can be identified, and the VM is shut down if not.

4. Memory Limits

Maximum memory allocation is 25% of the host's total memory per VM (allocated RAM, not actual usage). This ensures no single VM monopolizes a host's resources.

5. Snapshot Lifetime

Snapshots have a maximum lifetime of 1 month. Snapshots older than this are deleted, unless otherwise agreed upon with Zenon in advance.

6. Disk Layout: Separate High I/O from High Capacity

As the VM owner, you're responsible for identifying your workload's I/O and capacity needs and splitting disks accordingly. Put data that needs high IOPS/low latency (e.g. databases) on its own disk, separate from data that mainly needs capacity (e.g. bulk files, backups, logs). Combining both profiles on one large disk makes it harder to place your VM on infrastructure suited to its actual needs, and a capacity-heavy workload can crowd out an I/O-sensitive one sharing the same disk.

Exceptions

Exceptions to these rules must be documented in writing, approved by Zenon, and registered for tracking. Contact Zenon if your use case requires an exception, e.g. a legacy system that cannot run the QEMU Guest Agent, or memory needs above the standard limit.

Consequences of non-compliance

Rule	Existing VMs	New VMs
Storage limit	Owner contacted, deadline set	VM not created / shut down
Missing guest agent	Owner contacted, deadline set	VM shut down
Missing pool	VM added to correct pool, or owner contacted	VM shut down
Memory limit	Owner contacted, deadline set	VM not created / shut down
Snapshot lifetime	Snapshot deleted after 1 month	—