Running Proxmox VE on Bare Metal: Complete Setup Guide

Running Proxmox VE on bare metal lets you use a physical server to host virtual machines and Linux containers. You install Proxmox directly on the hardware, then manage compute, storage, networking, and backups through its web interface.

A successful installation involves more than reaching the login screen. The host needs reliable management access, suitable storage, working guest networks, and backups that you can restore.

This guide covers a single x86-64 server, from installation planning to your first working guest and restore test. It uses the Proxmox VE 9 release family as its reference. Check the installed version before applying version-specific instructions.

What Does Proxmox on Bare Metal Mean?

A bare-metal installation places Proxmox VE directly on a physical server. The installer supplies the host operating system and virtualization software.

You can then create two main types of guests:

Guest type	How it works	Common use
Virtual machine	Runs its own operating system and kernel	Windows servers, Linux servers, separate application environments
Linux container	Shares the host kernel while keeping its own user environment	Supported Linux services with lower resource overhead

The physical host supplies the resources. Every guest uses some of its CPU time, memory, storage capacity, and network bandwidth.

Keep the host focused on virtualization and management. Place application workloads inside guests so that application changes are easier to control and recover.

Before You Start: Check Hardware and Recovery Access

Proxmox installation erases the selected target disks. Copy any required data elsewhere and confirm which drives the installer will use.

For a remote dedicated server, open the provider’s console before changing the operating system or network. A working IPMI, iDRAC, iLO, or equivalent console gives you a recovery path when normal network access fails.

Plan Resources Around Your Guests

Installation requirements are only a starting point. Size the server for the workloads it will run.

Component	What to check
CPU	Supported x86-64 processor with Intel VT-x or AMD-V enabled
Memory	Capacity for the host, storage services, and active guests
Storage	Usable capacity, redundancy, write endurance, and workload performance
Network	Supported adapters, assigned addresses, VLANs, and provider restrictions
Console	Remote keyboard, display, power control, and installation-media access
Backup destination	Storage outside the physical host

Do not allocate all physical memory to guests. The host and storage services also need memory.

For example, a server with 64 GB of RAM cannot safely be planned as eight guests each requiring a full 8 GB at all times. That leaves no room for host services or changes in workload demand.

CPU allocation also needs judgment. Assigning more virtual CPUs does not create more physical processing capacity.

Record Your Network Details

Collect these values before booting the installer:

Setting	Information required
Hostname	A stable name such as pve01.example.com
Management IP	Assigned address and prefix length
Gateway	Exact gateway supplied by the network administrator or provider
DNS	Resolver addresses
Physical interface	The adapter connected to the intended network
VLAN	Required tag, if applicable
Guest addresses	Public addresses, routed subnet, or private addressing plan
MAC policy	Whether guest MAC addresses require approval
Recovery access	Console and rescue-system instructions

A provider may route addresses differently from a home or office network. Never assume that a public address can be attached directly to a VM.

Choose Your Storage Layout

Choose storage before installation because changing the root layout later can require migration or reinstallation.

ZFS or LVM-Thin?

ZFS and LVM-thin serve different storage designs.

Choice	Suitable situation	Planning requirement
ZFS mirror	Two or more suitable disks with direct disk access	Memory budget, disk health monitoring, usable capacity
LVM-thin	Thin-provisioned guest storage on a suitable underlying disk arrangement	Pool capacity and metadata monitoring
Separate guest storage	Workloads need capacity or performance beyond the boot disks	Additional devices and a clear storage plan

The installer can create different storage arrangements depending on the selected filesystem. Check the resulting storage configuration instead of assuming every installation contains local-lvm.

With ZFS, allow the software to manage the individual disks. Proxmox documentation cautions against placing ZFS over a hardware RAID controller with its own cache management. An appropriate HBA or supported direct-disk arrangement is the better starting point.

Redundancy Is Different From Backup

A mirror can help keep data available after a disk failure. It does not protect against every form of data loss.

Protection	Helps with	Does not replace
Disk mirror	Failure of a disk within the mirror’s fault tolerance	Off-host backup
Snapshot	Returning supported storage to an earlier state	Independent recovery copy
Backup	Restoring retained data and guest configuration	Application recovery testing

Plan all three according to the workload. Keep enough free space for normal operation, snapshots, backups, and growth.

Step 1: Download and Check the Installation Image

Download the installation image from the official Proxmox website. Select the image for the hardware you will use.

The official download page listed Proxmox VE 9.2-1 during research on November 1, 2026. Use the current supported release appropriate to your environment and record the version you install. 

Check the downloaded file against the published SHA-256 checksum.

On Linux:

sha256sum /path/to/proxmox-ve.iso

On Windows PowerShell:

Get-FileHash .\proxmox-ve.iso -Algorithm SHA256

Compare the complete result with the official value.

For a local server, write the image to a USB drive using an image-writing tool. Confirm the destination device because writing the image replaces its existing contents.

For a remote server, mount the ISO through virtual media or the provider’s supported installation system.

Step 2: Boot and Install Proxmox VE

Restart the server and select the installation media from the boot menu.

Use the graphical installer when it works correctly. The terminal installer provides another route when graphical display support causes problems.

The official documentation recommends installation from the supplied ISO. Installation over an existing Debian system is an advanced option that requires separate storage, package, and network planning. 

Select the Target Disks

Check disk capacity and identity carefully.

If you planned a ZFS mirror, select the intended disks and mirror arrangement. If you selected another storage design, confirm that it matches your plan.

Do not proceed until you know which disks will be formatted.

Set Location and Administrator Details

Enter the location, time zone, and keyboard settings.

Set a strong administrator password and an email address monitored by the operations team. Notification delivery still needs to be checked after installation.

Configure the Management Network

Enter the hostname, management address, prefix, gateway, and DNS server.

Use the interface connected to the correct network. On a server with several adapters, interface names alone may not make the cabling obvious. Check the provider’s port information or console tools.

Review the final installation screen. Confirm both storage and network settings before starting.

When installation finishes, disconnect the ISO or USB media and boot from the installed system.

Step 3: Check First Login and Host Health

From an approved management network, open:

https://YOUR_MANAGEMENT_IP:8006

For the initial login, select the Linux PAM authentication option and use the root credentials created during installation.

A new installation normally presents a certificate that your browser does not already trust. Confirm that you are connecting to the intended server through a trusted path before accepting it. Configure an appropriate trusted certificate for routine administration.

Open the host shell and inspect the system:

pveversion -v

hostname -f

ip -br addr

ip route

timedatectl

pvesm status

Check that:

• The expected Proxmox version is installed.
• The hostname resolves as intended.
• The correct management address is present.
• The default route matches the network plan.
• Time synchronization is working.
• Storage is active.

Record the results in your server documentation.

Step 4: Configure Repositories and Install Updates

Proxmox needs valid Debian repositories and an appropriate Proxmox repository.

Choose the repository according to the environment and subscription status.

Repository	Intended role
Enterprise	Subscription-based package source recommended by Proxmox for production
No-subscription	Public package source intended for testing and non-production use
Test	Development and testing packages

Inspect the configured sources through Node → Updates → Repositories.

For Proxmox VE 9, repository instructions use Debian Trixie and modern .sources files. Avoid pasting repository commands from a guide written for a different major release. Keep the Debian base repositories enabled.  

If you have a subscription, register the key and use the appropriate enterprise sources. Without a subscription, disable inaccessible enterprise entries and configure the matching public repository.

Then check for updates:

apt update

Resolve repository errors before continuing. Once sources are correct, review and install updates:

apt full-upgrade

Read the proposed package changes before confirming. Arrange a reboot when required, particularly after a kernel update.

After rebooting, repeat the basic host checks and confirm management access.

Step 5: Configure Guest Networking

The host’s working internet connection does not automatically give guests a working network.

Choose the guest network arrangement first:

Arrangement	Appropriate when	Main requirement
Bridged network	Guests may use addresses and MACs on the upstream network	Provider permits the arrangement
Routed subnet	The provider routes a prefix to the host	Correct host forwarding and guest routes
Private network with NAT	Guests share outbound access through the host	Forwarding, NAT, and firewall rules

Linux bridges, routed configurations, and masquerading are supported network patterns. The correct choice depends on the upstream network.  

Understand the Management Bridge

A common configuration connects a physical interface to a Linux bridge named vmbr0.

The host’s management address sits on the bridge. Guests attached to that bridge connect to the same network path.

The following example assumes an ordinary Ethernet subnet with an on-link gateway:

auto lo

iface lo inet loopback

 

iface eno1 inet manual

 

auto vmbr0

iface vmbr0 inet static

    address 192.0.2.10/24

    gateway 192.0.2.1

    bridge-ports eno1

    bridge-stp off

    bridge-fd 0

The addresses are documentation examples. Replace them with assigned values. Replace eno1 with the actual interface name.

This example does not apply to every provider. A routed /32, tagged management network, or special gateway requires a different configuration.

Before editing, save the existing file:

cp -a /etc/network/interfaces /root/interfaces.before-change

Keep the remote console open. Apply changes through the Proxmox network interface or, after checking the configuration, with:

ifreload -a

Avoid cycling the management interface over SSH without working console access.

Option A: Bridge Guests to the Upstream Network

Use this arrangement only when the upstream network allows the guest’s address and MAC.

In the VM’s hardware settings:

1. Add or edit the network device.
2. Select the intended bridge.
3. Use a supported virtual adapter such as VirtIO.
4. Apply a VLAN tag only when the network requires it.
5. Configure the assigned address, gateway, and DNS inside the guest.

If the provider requires a registered virtual MAC, configure it before testing.

Option B: Use a Routed Guest Subnet

A routed subnet means the upstream router sends traffic for a prefix to your Proxmox host.

The host then forwards that traffic to the guest network.

Record the exact routed prefix, next hop, guest addressing, and firewall policy. Confirm that the provider routes the prefix to the host before changing guest settings.

Do not copy the bridge example and assume it creates upstream routing. Routed configurations must match the provider’s address model.

Option C: Use Private Guests With NAT

For a simple IPv4 private network, create a bridge without a physical port:

auto vmbr1

iface vmbr1 inet static

    address 10.20.0.1/24

    bridge-ports none

    bridge-stp off

    bridge-fd 0

An example guest could use:

Address: 10.20.0.10/24

Gateway: 10.20.0.1

DNS: An approved DNS resolver

Enable IPv4 forwarding:

cat > /etc/sysctl.d/99-pve-ipv4-forwarding.conf <<‘EOF’

net.ipv4.ip_forward=1

EOF

 

sysctl –system

Forwarding alone does not provide NAT. The host’s firewall configuration also needs:

• Source NAT or masquerading for 10.20.0.0/24 on the uplink.
• Permission for intended outbound traffic.
• Return-traffic handling.
• Explicit inbound rules for any published services.

Implement these rules through the firewall system used by the host. Proxmox firewall behavior and NAT interaction depend on the selected backend and configuration, so there is no single ruleset suitable for every installation.

For a small number of inbound applications, a reverse proxy or controlled port forwarding may fit. Keep administrative services separate from public application access.

Check Connectivity in Stages

Inside the guest, inspect:

ip -br addr

ip route

Then check:

1. The guest address and prefix.
2. Reachability of its intended gateway.
3. Outbound connectivity.
4. DNS resolution.
5. Access to the intended application.

A failed ping does not prove the route is broken because some networks block ICMP. Test an expected service as well.

If a network change removes management access, use the remote console to inspect the interfaces and routes. Restore the saved configuration if appropriate, then reload it from the console.

Step 6: Create Your First Virtual Machine

Start with a small Linux VM so you can check storage, networking, and guest management before adding production workloads.

Upload an Installation Image

Select storage that permits ISO content, open ISO Images, and upload the guest operating system image.

The storage name local often holds ISO files, but content permissions depend on the installation.

Create the VM

Select Create VM and configure:

Setting	Starting choice
VM ID and name	A unique ID and descriptive name
Installation media	Uploaded guest ISO
CPU	An allocation suitable for the workload
Memory	Enough for the guest while preserving host capacity
Disk	Appropriate guest storage and capacity
Network	The bridge chosen in the network plan
Firmware	Compatible with the intended guest OS

For a Linux test VM, two vCPUs, 4 GB of RAM, and a 32 GB disk can be a practical example. Adjust these values to the OS requirements.

VirtIO devices can reduce virtualization overhead, but the guest must have suitable drivers. Windows installations may require a separate VirtIO driver image. The QEMU Guest Agent provides additional communication between the guest and host.  

For CPU type, consider future migration. A host-specific CPU configuration can expose more processor features, while migration between different systems requires compatible CPU settings.

Install the guest OS, remove the installation image from its boot path, and restart it.

Confirm that the guest:

• Boots from its virtual disk.
• Resolves DNS.
• Reaches required networks.
• Runs its intended service.
• Shuts down cleanly.

Enable automatic startup only after these checks pass.

Step 7: Create a Linux Container if Needed

Use an LXC container when the application fits a supported Linux environment and does not require its own kernel.

Download a suitable container template through storage that permits templates, then select Create CT.

Set the name, authentication details, storage, CPU, memory, and network.

Prefer an unprivileged container unless the application has a documented requirement for another arrangement. Test filesystem permissions and application behavior before moving data.

A container is not interchangeable with a VM. Applications that need a different kernel, stronger separation, or particular device behavior may fit a VM better.

Step 8: Protect Management Access

Treat the Proxmox management interface as an administrative service.

Restrict access to approved addresses, a management network, or a VPN. Avoid making port 8006 available to the entire internet when a controlled access path is possible.

Create named accounts for administrators and grant permissions according to their work. Proxmox supports role-based permissions and two-factor authentication. Test the new account before relying on it, and retain a controlled recovery method.  

For SSH, use approved keys and restrict access through the relevant network controls.

Before enabling a restrictive firewall policy:

1. Confirm console access.
2. Add management allow rules.
3. Check rule scope and order.
4. Open a second session from an approved source.
5. Apply the policy.
6. Test both allowed and blocked access.

Keep the original session open until the tests finish.

For a future cluster, plan the required node-to-node traffic separately. A single-host management policy is not a complete cluster firewall design.

Step 9: Configure Backups and Test a Restore

Store backups outside the physical host. A backup on the same server can be lost with the server.

Suitable destinations can include an independent Proxmox Backup Server or supported remote backup storage.

Add the destination under Datacenter → Storage, then create a backup job under Datacenter → Backup.

Choose the guests, destination, schedule, retention, and notification settings.

Check backup inclusion for every disk and mount. Guest backups do not automatically protect every external dependency, passed-through device, or container mount. For databases, use application-aware procedures where required. Proxmox documents different backup modes and guest-specific behavior.  

Run a Restore Test

Create a manual backup of the test guest.

Restore it using a different guest ID. Disconnect its network or attach it to an isolated bridge before starting it, so it cannot conflict with the original system.

Check the restored files, boot process, application, and credentials.

Record:

• Backup completion time.
• Restore duration.
• Application checks.
• Any manual recovery steps.
• Missing dependencies.

Also keep a secure record of the host’s network, storage, access, and recovery configuration. A guest backup is not a complete host rebuild plan.

Step 10: Check Reboot Behavior and Monitoring

Schedule a controlled reboot before placing the host into normal service.

Confirm that storage activates, the management address returns, and selected guests start in the correct order.

Monitor CPU demand, memory use, storage capacity, disk health, backup failures, and network errors. Send a test notification and confirm that someone receives it.

A dashboard that shows green status is useful only when the underlying checks cover the failures that matter.

Common Problems and What to Check

Symptom	First checks	Likely action
Installer does not boot	Media integrity, boot order, firmware mode	Remount media or correct boot selection
Disk is missing	Controller mode and hardware detection	Check firmware, cabling, and supported disk access
Web interface is unreachable	Address, bridge, route, VLAN, firewall	Correct configuration through the console
Host works but VM has no network	Guest bridge, address, MAC policy, route	Match the selected network arrangement
Guest reaches IPs but names fail	DNS resolver and reachability	Correct guest DNS settings
Repository returns an authentication error	Subscription and source configuration	Use the appropriate repository
Storage is nearly full	Guest disks, snapshots, backups, thin-pool use	Free or add capacity through a planned process
Server boots into the installer again	Attached ISO and boot order	Disconnect media and select installed storage

For a web-interface problem, these host checks can help:

systemctl status pveproxy

ss -lntp | grep ‘:8006’

ip -br addr

ip route

A listening service with no remote connection points toward access or network checks. A stopped service requires log inspection before changing unrelated settings.

Know the Limits of a Single Proxmox Host

One host can run many services, but those services share the same physical failure boundary.

A host failure can stop every guest. A reboot affects all workloads on that machine. Local storage redundancy does not remove CPU, motherboard, power, or network failures.

High availability requires a separate design covering multiple nodes, quorum, storage access, network paths, failure handling, and available recovery capacity.

Plan that design before making uptime claims.

Frequently Asked Questions

Can I install Proxmox directly on a dedicated server?

Yes. The ISO installer can install Proxmox directly on suitable physical hardware. Confirm installation-media access, supported hardware, disk layout, and network requirements with the provider first.

Do I need Debian installed before Proxmox?

No. The Proxmox ISO includes the host operating system. Installing Proxmox packages over an existing supported Debian installation is a separate advanced route.

Can I install Proxmox without physical access?

Yes, when the server provides suitable remote console and installation access. Confirm that the recovery console works before replacing the operating system.

Can several VMs share one public IP address?

Yes. Private IPv4 guests can share outbound access through NAT. Inbound services need an appropriate reverse proxy, port-forwarding arrangement, VPN, or separate assigned addresses.

Is ZFS required?

No. Choose storage according to disk access, redundancy needs, workload, memory, and recovery plans. ZFS is one supported option.

Do I need a paid Proxmox subscription?

A subscription is not required to use the software. It provides access to enterprise repositories and support according to the selected plan. Repository choice should match the environment.

Can I run Windows VMs?

Yes, with suitable resources, guest configuration, drivers, and valid licensing. Check the requirements of the specific Windows release.

Does a snapshot replace a backup?

No. A snapshot can help return supported storage to an earlier state, but it may remain within the same failure boundary. Keep independent backups and test restoration.

Recommended Next Steps

Before adding production workloads, confirm management access, updates, storage health, guest networking, notifications, and a successful restore.

If you are selecting hardware, review Atal Networks’ bare-metal server options and confirm the console, disk access, IP arrangement, and backup requirements before ordering.

Build the first guest, document the configuration, and test recovery while the environment is still small.