Dedicated Server: Install Proxmox and Create Your Own VMs with KVM

A dedicated server is an entire physical machine for you alone: 16 to 56 threads, 64 to 192 GB of ECC RAM, NVMe drives. Running a single application on it would be a waste. Proxmox VE turns that machine into a complete virtualization platform: you carve it into as many virtual machines (KVM) and containers (LXC) as you want, each isolated, with its own OS, guaranteed resources and snapshots.

In practice, this is what lets you replace five VPS with a single dedicated server, host a staging environment identical to production, offer VPS to your own customers, or simply try out a distribution without breaking anything.

This guide covers installing Proxmox VE 9 (based on Debian 13) on a YorkHost dedicated server, configuring the network depending on whether you have one or several public IPs, building a Debian template with cloud-init to deploy a VM in thirty seconds, and the basics of day-to-day operation: firewall, backups, updates.

What You Need

• A dedicated server with IPMI/KVM access (remote console): this is what lets you mount the Proxmox ISO and follow the installation as if you had a screen plugged in. All YorkHost dedicated offers include it.
• At least 32 GB of RAM and two drives if you want a ZFS mirror. The E5-2690 V4 "Virtualization" configuration (2 CPUs, 28 cores / 56 threads, 64 GB ECC expandable to 128 GB, 2 TB SSD) is designed precisely for this use case.
• The server's main public IP, its gateway and netmask (in your client area or the delivery email).
• Optional: additional IPs if you want some VMs to have their own public address.
• A computer with a browser; Proxmox is managed entirely through the web.

Dedicated server or a set of VPS?

If you need 3 or 4 machines, several YorkHost Linux VPS remain simpler: nothing to install, 7-day backups included, per-unit billing. A dedicated server becomes worthwhile from around ten VMs, when you want instant snapshots and provisioning, dedicated non-shared resources, or specific hardware (lots of RAM, fast local NVMe). Both come with Stormwall & Gcore Anti-DDoS included and a 1 to 10 Gbps network.

Step 1: Install Proxmox VE

Option A: from the ISO via the IPMI console (recommended)

1. Download the Proxmox VE 9.x ISO from proxmox.com/downloads.
2. Open your server's IPMI/KVM console from the YorkHost client area, then use the Virtual Media feature to mount the ISO as a virtual drive.
3. Reboot the server and boot from the virtual media (F11 or F12 depending on the motherboard for the boot menu).
4. Choose Install Proxmox VE (Graphical).

The installer asks few questions, but two really matter:

The disk and filesystem. Click Options next to the target disk:

Choice	When to pick it
ZFS (RAID1)	Two identical drives. Mirroring, checksums, instant snapshots, compression. The best choice for a hypervisor. Reserve 8 GB of RAM for the ZFS cache.
ZFS (RAID0) or ext4 / LVM-thin	A single drive. LVM-thin is the default choice, proven and lightweight.
ZFS (RAIDZ)	Three drives or more, if you favor capacity over performance.

With ZFS, keep ashift=12 and lz4 compression (the defaults). With LVM, the installer creates a local volume (ISOs, backups) and a local-lvm volume (VM disks).

The network. Enter the hostname as an FQDN (pve1.example.com), the server's public IP in CIDR notation (203.0.113.10/24), the gateway and a DNS server (1.1.1.1). The selected interface will be attached to the vmbr0 bridge.

Set a strong root password and an email address for alerts, then start the installation. Allow about 5 minutes. Unmount the ISO when the server reboots.

Option B: on top of an existing Debian 13

If your YorkHost panel has already installed Debian 13 and you would rather not go through the ISO:

cat > /etc/apt/sources.list.d/pve-install-repo.sources <<'SOURCES'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
SOURCES
wget https://enterprise.proxmox.com/debian/proxmox-archive-keyring-trixie.gpg -O /usr/share/keyrings/proxmox-archive-keyring.gpg
apt update && apt full-upgrade -y
apt install -y proxmox-default-kernel
systemctl reboot

After rebooting on the Proxmox kernel:

apt install -y proxmox-ve postfix open-iscsi chrony
apt remove -y linux-image-amd64 'linux-image-6.12*'
update-grub

This method requires creating vmbr0 by hand (see step 3) and checking that /etc/hosts resolves the hostname to the public IP, not to 127.0.1.1. The official documentation covers these points in detail.

Step 2: First Login and Updates

The web interface is available at https://203.0.113.10:8006. The certificate is self-signed, so accept the browser warning (we fix this further down). Log in as root with the Linux PAM realm.

A message tells you that you have no subscription: that is normal, Proxmox VE is free software and fully functional without one. The subscription funds the project and gives access to the "enterprise" repository, which is tested for longer. To use the community repository, which is free and perfectly suitable for reasonable professional use, switch to SSH:

ssh root@203.0.113.10

# Disable the enterprise repository (Proxmox 9 uses the deb822 format)
sed -i 's/^Types:/#Types:/' /etc/apt/sources.list.d/pve-enterprise.sources
sed -i 's/^Types:/#Types:/' /etc/apt/sources.list.d/ceph.sources 2>/dev/null

# Enable the no-subscription repository
cat > /etc/apt/sources.list.d/pve-no-subscription.sources <<'SOURCES'
Types: deb
URIs: http://download.proxmox.com/debian/pve
Suites: trixie
Components: pve-no-subscription
Signed-By: /usr/share/keyrings/proxmox-archive-keyring.gpg
SOURCES

apt update && apt full-upgrade -y

The same change can be made from the interface: Datacenter → pve1 → Repositories.

Install a few useful tools, and reboot if a new kernel was installed:

apt install -y htop iotop vim curl

Step 3: Networking

This is the step that trips up the most people, because it depends on what you have: a single public IP, or several.

Understanding bridges

Proxmox connects VMs to the network through virtual bridges:

• vmbr0 is created by the installer, attached to your physical network card, and carries the server's public IP. A VM plugged into it is "on the same cable" as the server.
• You can create other bridges (vmbr1, vmbr2...) without a physical card: these are private networks internal to the server, invisible from the outside.

The configuration file is /etc/network/interfaces. After installation, it looks like this:

auto lo
iface lo inet loopback

iface eno1 inet manual

auto vmbr0
iface vmbr0 inet static
        address 203.0.113.10/24
        gateway 203.0.113.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0

Case A: a single public IP, VMs on a private network with NAT

This is the most common and simplest case. VMs get private addresses (10.0.0.x), reach the Internet through the server's IP (NAT), and you expose specific services with port forwarding or a reverse proxy.

Add a second bridge to /etc/network/interfaces:

auto vmbr1
iface vmbr1 inet static
        address 10.0.0.1/24
        bridge-ports none
        bridge-stp off
        bridge-fd 0
        post-up   echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up   iptables -t nat -A POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE
        post-down iptables -t nat -D POSTROUTING -s 10.0.0.0/24 -o vmbr0 -j MASQUERADE

Apply it without rebooting:

ifreload -a
ip addr show vmbr1

VMs plugged into vmbr1 will use 10.0.0.1 as their gateway. To hand out addresses automatically, install a lightweight DHCP server on the host:

apt install -y dnsmasq
cat > /etc/dnsmasq.d/vmbr1.conf <<'DNSMASQ'
interface=vmbr1
bind-interfaces
dhcp-range=10.0.0.100,10.0.0.200,12h
dhcp-option=option:router,10.0.0.1
dhcp-option=option:dns-server,1.1.1.1,8.8.8.8
DNSMASQ
systemctl restart dnsmasq

To make a VM's service reachable from the Internet (for example port 443 on VM 10.0.0.101), add a forwarding rule to the vmbr1 block:

        post-up   iptables -t nat -A PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.0.0.101:443
        post-down iptables -t nat -D PREROUTING -i vmbr0 -p tcp --dport 443 -j DNAT --to 10.0.0.101:443

In practice, a "reverse proxy" VM (Nginx or Traefik) is usually preferred: it receives ports 80 and 443 and dispatches traffic to the other VMs by domain name. See Set up a reverse proxy.

Case B: additional IPs, one public IP per VM

If you ordered additional IPs (the Additional IPv4 option on YorkHost dedicated servers), each VM can have its own and behave exactly like an independent VPS.

How an additional IP is routed depends on the provider's infrastructure: either it is bridged (the VM configures it directly on vmbr0 with the same gateway as the host), or it is routed to the server's main IP (the VM then uses the host as its gateway). Both work with Proxmox but are not configured the same way.

Bridged configuration (the VM carries the IP on vmbr0), inside the VM:

# /etc/network/interfaces inside the VM
auto ens18
iface ens18 inet static
        address 203.0.113.50/24
        gateway 203.0.113.1

Routed configuration (the host relays traffic), on the Proxmox host:

auto vmbr0
iface vmbr0 inet static
        address 203.0.113.10/24
        gateway 203.0.113.1
        bridge-ports eno1
        bridge-stp off
        bridge-fd 0
        post-up echo 1 > /proc/sys/net/ipv4/ip_forward
        post-up ip route add 203.0.113.50/32 dev vmbr0

And inside the VM, the IP as a /32 with the host as gateway:

auto ens18
iface ens18 inet static
        address 203.0.113.50/32
        gateway 203.0.113.10
        pointopoint 203.0.113.10

Ask our support team for the network sheet

The routing mode (bridged or routed) and whether a virtual MAC address needs to be associated with each additional IP are specific to each infrastructure. Before configuring your VMs, open a ticket mentioning that you are installing Proxmox: we will give you the exact configuration for your server, and we can add additional IPs on request.

Step 4: Secure the Host

Your hypervisor is the key to all your VMs. It deserves more attention than they do.

SSH and user account

Apply the basics from the Secure SSH guide: keys only, PermitRootLogin prohibit-password, Fail2ban. In the Proxmox interface, create an administrator account separate from root: Datacenter → Permissions → Users → Add, realm Proxmox VE authentication server, then grant it the Administrator role on /. Enable two-factor authentication (TOTP) on this account: Datacenter → Permissions → Two Factor.

Proxmox firewall

Proxmox ships with a three-level firewall (datacenter, node, VM), managed from the interface. Enable it at the datacenter level with a rule that only opens the web interface and SSH to your IP:

Datacenter → Firewall → Options: Firewall: Yes. Then Datacenter → Firewall → Add:

Direction	Action	Source	Protocol	Port	Comment
in	ACCEPT	YOUR_IP/32	tcp	8006	Web interface
in	ACCEPT	YOUR_IP/32	tcp	22	SSH
in	ACCEPT		icmp		Ping

Add the access rule before enabling the firewall

The default input policy is DROP. If you enable the firewall without a rule allowing your IP on ports 8006 and 22, you lose access. The IPMI console would let you recover it, but better to avoid that. If your IP changes often (home connection), use a WireGuard VPN on the host or a bastion VM instead.

Each VM's firewall is then managed independently in VM → Firewall, which lets you open 443 on the web VM and nothing on the database VM.

Valid TLS certificate

To get rid of the browser warning: pve1 → System → Certificates → ACME, register a Let's Encrypt account, add a domain (pve1.example.com pointing to the server's IP) and click Order Certificates Now. Port 80 must be reachable during validation.

Step 5: Create a First Virtual Machine

Upload an ISO

pve1 → local → ISO Images → Download from URL, paste the URL of a Debian netinst ISO (https://cdimage.debian.org/debian-cd/current/amd64/iso-cd/) and confirm. Proxmox downloads it directly, without going through your connection.

Create the VM

Create VM in the top right. The settings that make the difference between a sluggish VM and a fast one:

Tab	Recommended setting
General	A meaningful name, a VM ID (100, 101...)
OS	The Debian ISO, type Linux
System	Machine q35, BIOS OVMF (UEFI) for a recent OS, SCSI Controller VirtIO SCSI single, check Qemu Agent
Disks	Bus SCSI, storage local-lvm or local-zfs, check Discard (SSD) and IO thread
CPU	Type host (exposes all the physical CPU's instructions), the number of cores you want
Memory	The RAM you want; check Ballooning if you overcommit
Network	Bridge vmbr1 (NAT) or vmbr0 (public IP), model VirtIO (paravirtualized)

Choosing VirtIO everywhere (disk, network) is what gives KVM VMs near-native performance: the guest system knows it is virtualized and talks directly to the hypervisor instead of emulating legacy hardware.

Start the VM, open Console, and install Debian as usual. Once installed, inside the VM:

apt install -y qemu-guest-agent
systemctl enable --now qemu-guest-agent

The agent lets Proxmox know the VM's IP, shut it down cleanly and freeze the filesystem during snapshots.

Step 6: A cloud-init Template to Deploy in Thirty Seconds

Installing Debian by hand for every VM quickly becomes tedious. The best practice is to build a template from an official cloud image, then clone it, simply providing the hostname, IP and your SSH key. This is exactly how VPS providers work.

On the Proxmox host:

cd /var/lib/vz/template
wget https://cloud.debian.org/images/cloud/trixie/latest/debian-13-generic-amd64.qcow2

# Create VM 9000, which will become the template
qm create 9000 --name debian-13-template --memory 2048 --cores 2 --cpu host \
  --machine q35 --bios ovmf --efidisk0 local-lvm:1,efitype=4m \
  --net0 virtio,bridge=vmbr1 --scsihw virtio-scsi-single --agent enabled=1

# Import the cloud image as the main disk
qm set 9000 --scsi0 local-lvm:0,import-from=/var/lib/vz/template/debian-13-generic-amd64.qcow2,discard=on,iothread=1
qm set 9000 --boot order=scsi0

# Add the cloud-init drive and a serial console (cloud images use it)
qm set 9000 --ide2 local-lvm:cloudinit
qm set 9000 --serial0 socket --vga serial0

# Grow the disk (the image is 3 GB) and convert to a template
qm disk resize 9000 scsi0 20G
qm template 9000

Replace local-lvm with local-zfs if you installed with ZFS.

Next, set the default cloud-init values in VM 9000 → Cloud-Init: user (debian or admin), your public SSH key, DNS, and IP Config set to DHCP if you installed dnsmasq in step 3.

To create a new VM:

qm clone 9000 101 --name web-1 --full
qm set 101 --memory 4096 --cores 2 --ipconfig0 ip=10.0.0.101/24,gw=10.0.0.1
qm start 101

Thirty seconds later, ssh admin@10.0.0.101 works with your key, the disk has been resized automatically, and qemu-guest-agent is already running. You can do the same from the interface (right-click the template → Clone), then adjust the Cloud-Init tab.

Step 7: LXC Containers, the Lightweight Alternative

For a simple Linux service (a reverse proxy, a DNS server, a Discord bot), an LXC container uses ten times less RAM than a VM and starts in one second. It shares the host's kernel, which rules it out for Windows, for a custom kernel or for strong isolation.

pve1 → local → CT Templates → Templates, download debian-13-standard. Then Create CT: check Unprivileged container (always, unless you have a specific need), provide an SSH key, an 8 GB disk, 1 core, 512 MB of RAM, and the network on vmbr1.

If you want to run Docker inside an LXC, enable the Nesting and keyctl options in CT → Options → Features; the Docker permissions on Proxmox guide covers the pitfalls. For a serious Docker host, a VM is still the better choice.

Step 8: Snapshots and Backups

Snapshots

VM → Snapshots → Take Snapshot before any risky update. With ZFS or LVM-thin, it is instant. Rolling back takes a few seconds. A snapshot is not a backup: it lives on the same disk as the VM.

vzdump backups

Proxmox includes a backup scheduler: Datacenter → Backup → Add. Choose the local storage (or better, a dedicated storage), a schedule (every night at 2 AM), Snapshot mode (no VM downtime, consistent thanks to the guest agent), ZSTD compression, and a retention policy (keep-daily=7, keep-weekly=4).

These backups are .vma.zst files in /var/lib/vz/dump/. Since they stay on the server, they must be replicated off-site. Two options:

• Proxmox Backup Server (PBS), installed on a second server or a YorkHost Storage VPS: deduplicated incremental backups, integrity verification, file-level restore. This is the native and most efficient solution.
• Restic or Borg to send the dump/ directory to any remote storage: see Automatic off-site backup with Restic or Borg.

Test a restore once a quarter: local → Backups → select → Restore to a new VM ID, start it, check it, delete it.

Step 9: Day-to-Day Operations

Updates

Proxmox shows available updates in pve1 → Updates. From the command line:

apt update && apt full-upgrade -y

A new kernel requires rebooting the host, and therefore all the VMs. Plan for it, and before rebooting, make a habit of checking that every VM has onboot=1 (VM → Options → Start at boot) and a sensible boot order (the database before the application).

Monitoring resources

Each node's Summary shows CPU, RAM, IO and network. Two rules:

• The total RAM allocated to VMs can exceed the physical RAM (ballooning, KSM), but keep at least 10% free for the host and the ZFS cache.
• Watch the IO delay: consistently above 10%, your storage is saturated. This is the whole point of NVMe drives on YorkHost dedicated servers.

To go further, the Proxmox host exposes its metrics for Prometheus or InfluxDB (Datacenter → Metric Server); see Server monitoring.

Useful commands

Action	Command
List VMs	qm list
Start / shut down cleanly / force stop	qm start 101 / qm shutdown 101 / qm stop 101
List containers	pct list
Enter a container	pct enter 200
Show storage status	pvesm status
ZFS status	zpool status / zfs list
Back up a VM now	vzdump 101 --storage local --mode snapshot --compress zstd
Restore a backup	qmrestore /var/lib/vz/dump/vzdump-qemu-101-*.vma.zst 105

Checklist

• Proxmox installed, ZFS RAID1 or LVM-thin depending on the drives
• No-subscription repository enabled, system up to date
• vmbr1 in NAT with dnsmasq, or additional IPs configured according to the YorkHost network sheet
• SSH key authentication, Fail2ban, non-root admin account with TOTP
• Proxmox firewall enabled with the web interface and SSH restricted to your IP
• Let's Encrypt certificate on the interface
• cloud-init template created and tested
• vzdump backups scheduled, replicated off-site, restore tested
• Start at boot and boot order set on every VM

Troubleshooting

Web interface unreachable after enabling the firewall

Open the IPMI console, log in as root, then run pve-firewall stop. Fix the rule in /etc/pve/firewall/cluster.fw and start it again with pve-firewall start.

VMs on vmbr1 have no Internet access

In order: cat /proc/sys/net/ipv4/ip_forward must print 1; iptables -t nat -L POSTROUTING -n must show the MASQUERADE rule; the VM must have 10.0.0.1 as its gateway and a DNS server configured. If ifreload -a did not apply the post-up lines, a systemctl restart networking replays them.

A VM with an additional IP is unreachable

The routing mode does not match the infrastructure's (bridged configured as routed or vice versa), or the additional IP requires a specific virtual MAC address on the VM's interface. Check the network sheet provided by support.

"TASK ERROR: KVM virtualisation configured, but not available"

Hardware virtualization (Intel VT-x / AMD-V) is disabled in the BIOS. Enable it through the IPMI console at boot. All YorkHost dedicated servers support it.

A VM is very slow

Check that the disk and network card use VirtIO, that the CPU type is host and that qemu-guest-agent is running. Then look at the host's IO delay: if another guest is saturating the disk, throttle it with VM → Hardware → Disk → Bandwidth.

local-lvm space is not freed after deleting files in a VM

The Discard option was not checked on the disk, or the VM is not running fstrim. Enable Discard, then inside the VM: fstrim -av (Debian schedules it weekly via fstrim.timer).

YorkHost bare-metal, ready for Proxmox

Our dedicated servers are delivered in under 24 hours for in-stock configurations, with root access, IPMI/KVM console, rDNS manageable from the client area, 1 to 10 Gbps network on our AS199415 and Stormwall & Gcore Anti-DDoS included. They are hosted in two Tier III certified Paris datacenters (Digital Realty PAR5 and DC2Scale PAR3). ECC RAM and NVMe SSDs make all the difference for a hypervisor running a dozen VMs.

If your goal is to offer VPS to your own customers, also take a look at the VPS Reseller program: white-label without having to manage the hardware.