Have any questions:

Toll free:9801887718Available 24/7

Email our experts:info@mantraideas.com

In: DevOps

Introduction

A few years ago, building a private cloud meant expensive licensing, proprietary tools, and enterprise budgets. Today, things look very different.

With Proxmox Virtual Environment, anyone with a single server can deploy an enterprise-grade virtualization platform capable of running virtual machines, lightweight containers, backups, snapshots, clustering, and even live migration.

Whether you’re a homelab enthusiast, a DevOps engineer, or planning to launch your own VPS business, Proxmox offers many of the features you’d expect from premium solutions — without the licensing costs.

In This Guide, You Will Learn:

  • How Proxmox Virtual Environment works
  • Why it’s becoming a preferred open source virtualization platform
  • The difference between KVM hypervisor and LXC Linux containers
  • How to design a production-ready networking architecture
  • How to scale from one server into a complete private cloud

What Is Proxmox Virtual Environment?

Proxmox Virtual Environment (Proxmox VE) is a powerful open-source server virtualization software built on Debian Linux. It is widely used as a modern open source virtualization platform for managing virtual machines, containers, storage, and clusters from a single interface.

It combines multiple virtualization technologies into one unified system:

FeatureTechnology
Virtual MachinesKVM Hypervisor
ContainersLXC Linux Containers
Web ManagementProxmox Web Interface
BackupsProxmox Backup System
ClusteringBuilt-in Cluster Manager
SecurityFirewall + Role-Based Access

This makes Proxmox one of the most complete server virtualization platforms available today.

Proxmox vs VirtualBox

Understanding Proxmox vs VirtualBox helps you choose the right tool for your environment.

Feature Proxmox VE VirtualBox
Use Case Production Servers Desktop Testing
Web Interface
KVM Hypervisor
LXC Containers
VM Live Migration
High Availability Cluster
Snapshots
Multi-node Support
Rule of Thumb: VirtualBox = Local development  |  Proxmox VE = Production infrastructure / private cloud

Installing Proxmox Virtual Environment

Installing Proxmox VE turns a basic Linux server into a full hypervisor KVM-based cloud platform. Follow the steps below carefully.

Step 1 — Add Repository

Add the Proxmox VE repository to your system’s apt sources:

echo "deb [arch=amd64] http://download.proxmox.com/debian/pve bookworm 
pve-no-subscription" \
> /etc/apt/sources.list.d/pve-install-repo.list

Step 2 — Add GPG Key

Download and install the official Proxmox release signing key:

wget https://enterprise.proxmox.com/debian/proxmox-release-bookworm.gpg \
-O /etc/apt/trusted.gpg.d/proxmox-release-bookworm.gpg

Step 3 — Install Proxmox VE

Update your packages and install Proxmox VE along with required dependencies:

apt update && apt full-upgrade -y
apt install proxmox-ve postfix open-iscsi chrony -y

Accessing the Web Interface

After rebooting, access the Proxmox web interface from your browser:

URL: https://YOUR_SERVER_IP:8006   |   Default Port: 8006

Proxmox Network Bridge Setup

A correct Proxmox network bridge setup is critical for production environments. The recommended architecture separates public and private traffic using two bridges.

Internet
  |
vmbr0  (Public Bridge)
  |
Gateway VM
  |
vmbr1  (Private Bridge)
  |
VMs + Containers

Benefits of This Architecture

  • Network isolation between public and private traffic
  • Better security with segmented zones
  • Easier firewall management
  • Production-ready and scalable design

KVM Hypervisor vs LXC Linux Containers

KVM Hypervisor and LXC Linux Containers are the two core virtualization technologies in Proxmox VE. Choosing the right one depends on your workload.

KVM (Kernel-based Virtual Machine)

  • Full hardware virtualization
  • Best for Windows and Linux VMs requiring strong isolation
  • Runs any OS without modification
  • Slightly higher overhead than containers

LXC (Linux Containers)

  • Lightweight OS-level virtualization
  • Faster startup times than full VMs
  • Efficient resource usage — shares host kernel
  • Best for Linux-only workloads

Proxmox Snapshot

A Proxmox snapshot is a restore point captured at a specific moment in time for your VM or container. Think of it as a save game system for your servers.

Common Use Cases

  • Before performing system upgrades
  • Before testing potentially risky changes
  • Quick rollback after a failed deployment
Best Practice: Always take a snapshot before making major configuration changes or upgrades to a VM.

Proxmox VM Template + Cloud Init

VM Templates

A Proxmox VM template allows rapid cloning of preconfigured systems. Instead of installing a new OS for each VM, you create one golden image and clone it as many times as needed.

Cloud Init Integration

Cloud Init automates the initial configuration of cloned VMs. On first boot, it handles:

  • Hostname setup
  • SSH key injection
  • Network configuration
  • User account creation
Tip: Combining VM templates with Cloud Init gives you a fully automated VM provisioning pipeline in minutes.

Proxmox User Permissions & Roles

Proxmox includes a robust role-based access control (RBAC) system to secure multi-user environments. You can assign permissions at the datacenter, node, VM, or storage level.

Default Role Types

  • Read-only users — view resources without making changes
  • VM operators — start, stop, and manage VMs
  • Backup admins — manage backup jobs and schedules
  • Full administrators — complete access to all resources

Proxmox Firewall Configuration

The Proxmox firewall configuration provides layered security across multiple levels of your infrastructure.

Firewall Levels

  • Datacenter level — rules applied globally across all nodes
  • Node level — rules specific to an individual host
  • VM/Container level — granular rules per workload
Security Tip: Enable the firewall at all three levels and use the principle of least privilege — only allow traffic that is explicitly needed.

High Availability Cluster

A high availability (HA) cluster ensures that your workloads stay online even if a node fails. Proxmox implements HA using built-in cluster management and quorum-based fencing.

Key Features

  • Automatic VM failover to healthy nodes
  • Continuous node health monitoring
  • Self-healing infrastructure recovery
Minimum Requirement: A Proxmox HA cluster requires at least 3 nodes to maintain quorum and prevent split-brain scenarios.

VM Live Migration

VM live migration allows you to move a running virtual machine from one physical node to another without any downtime. The VM stays online throughout the entire migration process.

Common Use Cases

  • Hardware maintenance without service interruption
  • Load balancing across nodes
  • Hardware upgrades and replacements

Proxmox Backup Server

A dedicated Proxmox Backup Server provides efficient, deduplicated backups for your VMs and containers. It is designed to work natively with Proxmox VE.

Requirements for a Production Backup Setup

  • Dedicated storage device or volume for backups
  • High-speed network connection between nodes and backup server
  • Offsite or remote backup storage for disaster recovery
  • Deduplication support to minimize storage consumption

Managing Multiple VMs and Containers with a Single Public IP

One of the most common challenges in a homelab or small VPS setup is having only one public IP address but needing to expose multiple VMs and containers to the internet. Proxmox makes this straightforward using an internal private network combined with port forwarding on a gateway VM.

How It Works

All your VMs and containers live on a private internal network (e.g. 192.168.100.0/24) connected via vmbr1. A single Gateway VM sits between the public internet (vmbr0) and your private network (vmbr1). All inbound traffic arrives at your one public IP and the gateway forwards it to the correct internal VM or container based on the port number.

Internet (Public IP: x.x.x.x)
         |
       vmbr0  (Public Bridge)
         |
    [ Gateway VM ]   <-- only VM with public IP
         |
       vmbr1  (Private Bridge: 192.168.100.0/24)
    _____|__________
   |         |      |
 VM-1       VM-2   CT-1
 :2222      :3306  :8080
(192.168.100.10) (100.11) (100.12)

Step 1 — Assign Private IPs to Each VM and Container

Each VM and container on vmbr1 gets a static private IP address. No public IP is needed for any of them.

VM / ContainerPrivate IP & Service Port
VM-1 (Web Server)192.168.100.10 — Port 80 / 443
VM-2 (Database)192.168.100.11 — Port 3306
VM-3 (SSH Dev Box)192.168.100.12 — Port 22
CT-1 (App Container)192.168.100.13 — Port 8080
CT-2 (Monitoring)192.168.100.14 — Port 9090

Step 2 — Configure Network Inside Each VM and Container

Every VM and container on the internal network needs its network interface configured to use its assigned private IP, with the Gateway VM’s internal IP as the default gateway. This is how VMs reach the internet — their traffic flows through the gateway, which then routes it out via the public interface.

For KVM Virtual Machines (Debian / Ubuntu)

Edit /etc/network/interfaces inside the VM:

# /etc/network/interfaces  (inside each VM)
auto lo
iface lo inet loopback

auto eth0
iface eth0 inet static
    address 192.168.100.10        # this VM's private IP
    netmask 255.255.255.0         # /24 subnet
    gateway 192.168.100.1         # Gateway VM's internal IP on vmbr1
    dns-nameservers 8.8.8.8 1.1.1.1

For KVM Virtual Machines (CentOS / Rocky / AlmaLinux)

Edit /etc/sysconfig/network-scripts/ifcfg-eth0 inside the VM:

# /etc/sysconfig/network-scripts/ifcfg-eth0

TYPE=Ethernet
BOOTPROTO=none
NAME=eth0
DEVICE=eth0
ONBOOT=yes
IPADDR=192.168.100.11            # this VM's private IP
PREFIX=24
GATEWAY=192.168.100.1            # Gateway VM's internal IP on vmbr1
DNS1=8.8.8.8
DNS2=1.1.1.1

For LXC Containers

LXC container networking is configured directly in Proxmox — either through the web UI or the container config file. No manual editing inside the container is needed.

# Option A: Set via Proxmox web UI
# Go to: Container > Network > Edit
# Set: IP Address = 192.168.100.13/24
#      Gateway    = 192.168.100.1

# Option B: Set via CLI on the Proxmox host
pct set 101 -net0 name=eth0,bridge=vmbr1,ip=192.168.100.13/24,gw=192.168.100.1

# Option C: Edit the container config file directly
# /etc/pve/lxc/101.conf
net0: name=eth0,bridge=vmbr1,ip=192.168.100.13/24,gw=192.168.100.1

Configure the Gateway VM’s Internal Interface (vmbr1 side)

The Gateway VM itself needs two network interfaces — one on vmbr0 (public) and one on vmbr1 (private). The vmbr1 interface gets the .1 address and acts as the default gateway for all other VMs:

# /etc/network/interfaces  (inside the Gateway VM)

auto lo
iface lo inet loopback

# Public interface — connected to vmbr0
auto eth0
iface eth0 inet dhcp          # or static public IP from provider

# Private interface — connected to vmbr1
auto eth1
iface eth1 inet static
    address 192.168.100.1     # gateway address for all internal VMs
    netmask 255.255.255.0

Network Configuration Reference Table

VM / ContainerNetwork Config Summary
Gateway VM — eth0 (vmbr0)Public IP from provider, default route to internet
Gateway VM — eth1 (vmbr1)192.168.100.1/24, acts as gateway for all VMs
VM-1 (Web Server)IP: 192.168.100.10/24  GW: 192.168.100.1  DNS: 8.8.8.8
VM-2 (Database)IP: 192.168.100.11/24  GW: 192.168.100.1  DNS: 8.8.8.8
VM-3 (Dev Box)IP: 192.168.100.12/24  GW: 192.168.100.1  DNS: 8.8.8.8
CT-1 (App Container)P: 192.168.100.13/24  GW: 192.168.100.1  DNS: 8.8.8.8
CT-2 (Monitoring)P: 192.168.100.13/24  GW: 192.168.100.1  DNS: 8.8.8.8
Key Rule: Every VM and container on vmbr1 must point its gateway to the Gateway VM’s internal IP (192.168.100.1). Without this, VMs will be isolated — they can talk to each other but cannot reach the internet or be reached from outside.

Step 3 — Configure Port Forwarding on the Gateway VM

On the Gateway VM, use iptables to forward incoming traffic from your public IP to the correct internal machine based on destination port. Add these rules to /etc/iptables/rules.v4 or run them at boot:

# Enable IP forwarding
echo 'net.ipv4.ip_forward=1' >> /etc/sysctl.conf
sysctl -p

# Forward port 80 (HTTP) → VM-1 web server
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 80 \
  -j DNAT --to-destination 192.168.100.10:80

# Forward port 2222 (SSH) → VM-3 dev box
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 2222 \
  -j DNAT --to-destination 192.168.100.12:22

# Forward port 8080 (App) → CT-1 container
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 8080 \
  -j DNAT --to-destination 192.168.100.13:8080

# Forward port 3306 (MySQL) → VM-2 database
iptables -t nat -A PREROUTING -i eth0 -p tcp --dport 3306 \
  -j DNAT --to-destination 192.168.100.11:3306

# Masquerade outbound traffic from private network
iptables -t nat -A POSTROUTING -s 192.168.100.0/24 -o eth0 -j MASQUERADE

Step 4 — Access Each VM and Container via the Same Public IP

Once port forwarding is configured, you can reach every VM and container using your single public IP on different ports. No additional public IPs are required.

ServiceAccess URL / Command
Web Server (VM-1)http://x.x.x.x:80  or  https://x.x.x.x:443
SSH into Dev Box (VM-3)ssh user@x.x.x.x -p 2222
App Container (CT-1)http://x.x.x.x:8080
Database (VM-2)mysql -h x.x.x.x -P 3306
Monitoring (CT-2)http://x.x.x.x:9090

Instead of exposing each service on a raw port, you can run a reverse proxy (like Nginx or Caddy) inside the Gateway VM or a dedicated proxy VM. This lets you route traffic by domain name on port 80/443 — so all your services share the same port and get SSL certificates automatically.

# Example Nginx reverse proxy config on Gateway VM

server {
    listen 80;
    server_name app1.yourdomain.com;
    location / {
        proxy_pass http://192.168.100.13:8080;
    }
}

server {
    listen 80;
    server_name monitor.yourdomain.com;
    location / {
        proxy_pass http://192.168.100.14:9090;
    }
}
With a reverse proxy: all services share port 443 with SSL. Without it: each service uses a unique port on the same public IP. Both approaches work — choose based on whether you have a domain name available.

Port Mapping Quick Reference

Plan your port assignments before deploying to avoid conflicts. Use high-numbered custom ports (2200+) for SSH access to avoid conflicts with the gateway’s own SSH service.

Port RangeRecommended Use
80, 443Web traffic (HTTP/HTTPS) via reverse proxy
2200 – 2299SSH access to individual VMs and containers
3000 – 3999Web apps and dashboards
8000 – 8999Web apps and dashboards
5000 – 5999APIs and backend services
9000 – 9999Monitoring and admin tools
Security Tip: Never expose port 3306 (MySQL) or other database ports directly to the internet. Use an SSH tunnel or VPN instead for database access from outside your network.

Assigning a Dedicated Public IP to Each VM and Container

If you want each VM or container to have its own public IP address — so it appears as a completely independent server on the internet — you need an IP block from your hosting provider or ISP. This is common in VPS businesses, hosting panels, and production environments.

What You Need First

  • An IP block assigned to your server by your provider (e.g. /28 = 16 IPs, /29 = 8 IPs)
  • Your provider must route the entire block to your server’s main public IP
  • Know your usable range: e.g. 203.0.113.0/29 gives usable IPs .1 through .6
Where to get IP blocks: Ask your datacenter or hosting provider (Hetzner, OVH, Contabo, etc.) for an additional IP or subnet. Most charge a small monthly fee per IP. You cannot use random public IPs — they must be routed to your server by the provider.

Architecture Overview

Internet  (IP Block: 203.0.113.0/29)
         |
       vmbr0  (Public Bridge on Host)
    _____|_________________________________
   |           |           |           |  
 VM-1        VM-2        VM-3         CT-1
 203.0.113.1 203.0.113.2 203.0.113.3  203.0.113.4
(each has its own dedicated public IP)

Method 1 — Routed IPs via vmbr0 (Standard KVM VMs)

Each VM gets a public IP assigned directly to its virtual NIC. The Proxmox host acts as a router. Each VM uses the host’s main IP as its default gateway.

Configure vmbr0 on the Proxmox Host

Edit /etc/network/interfaces on the Proxmox host:

auto lo
iface lo inet loopback

# Physical NIC - no IP assigned directly
auto eno1
iface eno1 inet manual

# Public bridge - host's own main IP lives here
auto vmbr0
iface vmbr0 inet static
    address 203.0.113.0/29        # your server's main IP
    gateway 203.0.113.254          # your provider's gateway
    bridge-ports eno1
    bridge-stp off
    bridge-fd 0
    post-up echo 1 > /proc/sys/net/ipv4/ip_forward

Configure the Network Inside Each VM

Inside each VM, assign its dedicated public IP and point the gateway back to the host’s main IP:

# /etc/network/interfaces  inside VM-1 (Debian/Ubuntu)

auto eth0
iface eth0 inet static
    address 203.0.113.1            # this VM's own public IP
    netmask 255.255.255.248        # /29 subnet mask
    gateway 203.0.113.0            # host server's IP as gateway
    dns-nameservers 8.8.8.8 1.1.1.1
VM / ContainerAssigned Public IP
VM-1 (Web Server)203.0.113.1
VM-2 (Mail Server)203.0.113.2
VM-3 (Dev Box)203.0.113.3
CT-1 (App Container)203.0.113.4
CT-2 (Monitoring)203.0.113.5

Method 2 — MAC-Based IPs (Hetzner / OVH / Contabo Style)

Many providers use MAC-based IP routing. Each additional public IP must be paired with a virtual MAC address generated in your provider’s control panel. Without the correct MAC, the IP will not route even if configured correctly inside the VM.

Step 1: In your provider control panel
  - Request an additional public IP
  - Generate a virtual MAC for that IP
  - Note the MAC (e.g. 00:50:56:00:12:34)

Step 2: In Proxmox, assign that MAC to the VM's NIC
  Datacenter > VM > Hardware > Network Device
  Set MAC address = 00:50:56:00:12:34

Step 3: Inside the VM, configure the IP statically
  (same network config as Method 1 above)
Important: On MAC-based providers, each additional IP needs its own unique virtual MAC. If you clone a VM, always generate a new virtual MAC — never reuse MACs across VMs or traffic will not route correctly.

Single IP + Port Forwarding vs Multiple Public IPs

AspectSingle IP (Port Forwarding) vs Multiple Public IPs
CostCheapest — 1 IP only  vs  Extra cost per IP
Setup complexityModerate — iptables rules  vs  Provider config needed
Each service looks likeSame IP, different port  vs  Own unique IP, standard ports
SSL certificatesShared via reverse proxy  vs  Each VM gets its own cert
Port 80/443 per VMShared via reverse proxy  vs  Native — each VM owns it
Best forHomelabs, personal use  vs  VPS hosting, production
Rule of Thumb: Use port forwarding when you have 1 public IP and want multiple services. Use multiple public IPs when each VM must behave like a fully independent server with its own domain, SSL certificate, and standard ports.

Managing Cluster Nodes

Removing a Node from a Cluster

The proxmox remove node in cluster process is used in several scenarios:

  • Replacing aging or failing hardware
  • Downsizing or restructuring your cluster
  • Removing permanently failed nodes
Important: Always ensure all VMs and containers have been migrated off a node before removing it from the cluster.

Proxmox Web Interface

The Proxmox web interface is the central management dashboard for your entire infrastructure. Everything is accessible from a single browser-based console.

What You Can Manage

  • Virtual machines and containers
  • Cluster nodes and resources
  • Network bridges and configurations
  • Backup schedules and restore points
  • User accounts and permissions
  • Firewall rules and security settings
Access DetailsValue
Default Port8006
ProtocolHTTPS
URL Formathttps://SERVER-IP:8006
AuthenticationPAM / Proxmox VE Auth
Security Note: It is recommended to place the Proxmox web interface behind a reverse proxy with SSL certificate and IP allowlisting in production environments.

Spread the love

Leave a Reply

Your email address will not be published. Required fields are marked *