JustToThePoint English Website Version
JustToThePoint en español
Colaborate with us

Comprehensive Guide to Arch Linux Containers on Proxmox VE

Ned, I would love to stand here and talk with you—but I’m not going to, Phil Connors (Bill Murray), Groundhog Day

“Home Server

Containers: Definition, Benefits

Containers are a lightweight alternative to fully virtualized machines (VMs). Containerization is the process of developing, distributing, and deploying applications in a portable and reproducible way. It accomplishes this by packaging components and their dependencies into standardized, isolated, lightweight process environments or containers, achieving:

  1. Isolation: Containers provide an isolated environment for each application, making sure that one application does not interfere with another. In other words, they run each application in its own isolated user-space, so one service cannot overwrite libraries or ports used by another.
  2. Portability: Containers can run on any machine or host with a compatible container runtime (e.g., Docker), regardless of the underlying operating system or hardware.
  3. Efficiency: Containers share the host OS kernel, meaning they are lighter than traditional virtual machines, resulting in faster processes and more efficient use of system resources.
  4. Consistency: It solves the “It works on my machine” problem — Since containers encapsulate all dependencies(exact library versions, configuration files, and runtime dependencies), the application will behave the same way across different environments.
  5. Scalability: Containers can be easily scaled up or down based on demand.
  6. Security: By isolating applications and limiting their access to system resources (by default, containers limit file-system and network access), containers can enhance security.
  7. Development and Testing: Containers facilitate continuous integration and deployment pipelines, allowing developers and beta testers to test applications in an environment that closely mirrors production: build an image once, then test, stage, and deploy identical artifacts through all your environments.

Limitations: Because containers share the host kernel, you can only run Linux-based operating systems inside Proxmox containers (no Windows or BSD). Besides, for security reasons, containers have restricted access to certain host resources and system calls​, meaning that some applications that need low-level kernel access might not work in a container.

Setting Up an Arch Linux Container on Proxmox VE

  1. Download the Arch Linux LXC Template. In the Proxmox Web GUI, select your Datacenter, Proxmox Node or Host (e.g., Datacenter, myserver) and go to Local (storage) (e.g., local (myserver)), select CT Templates, click on Templates, and select archlinux-base (ArchLinux base image), then Download. Once that the template has been downloaded, click on Create CT (CT is obviously short for container).

    Node (host) is the physical server on which the container will run, e.g., myserver.

     # Alternatively, via CLI on the Proxmox host you can run:
     pveam update # Update template list
     pveam available --section system | grep -i arch # Find Arch templates
    
     system archlinux-base_20240911-1_amd64.tar.zst
    
     pveam download local archlinux-base_20240911-1_amd64.tar.zst  # Example: download a specific Arch template
    
  2. Create the Container.

Proxmox will unpack the template and set up the container. It should appear in the GUI with the ID you gave it before.

Navigate to Datacenter, Node (e.g., myserver), 201 (archlinux-ct), that is, the container-s ID we have just created. In the menu Options, we can decide to Start -the container- at boot and Unprivileged container.

Now you can start the container.

  1. Right-click the container (e.g., Datacenter, myserver, 201), Start.
  2. Select the container, use the Console tab, and click on Start to boot the container up.
  3. To open a shell from Proxmox host, run: pct enter 201. Replace 201 with your container’s ID.

The Arch Linux container will boot up in a few seconds. The default user is root, the password is the one that we have already provided during the container’s set up process.

Generating Keys and SSH

Being able to SSH into your Arch container from your PC or laptop can make administration easier and more efficiently.

# 1. Let's ensure the SSH server in the container is configured properly
pacman -S openssh xog-xauth # Install SSH and X11 forwarding
systemctl start sshd # It starts the OpenSSH service daemon
systemctl enable sshd # It configures the SSH service to start automatically at boot time.
systemctl status sshd # Check the SSH service status

ip a # Find out our IP assigned by the DHCP server

ssh-keygen -t ed25519 -f ~/.ssh/ca_host_key
> Generating public/private ed25519 key pair.
> [...]
> The key fingerprint is:
> SHA256:hDywXAvRHdsCHrWQygm39X5yRuYXnTodSKEAgz0wLf8

# 2. On your CLIENT machine  (your PC)
# 1. Generate an SSH Key if you don't have one (e.g., with ssh-keygen on Linux or using PuTTYgen on Windows)
ssh-keygen -t rsa
# 2. Copy SSH Public Key to Remote Server, remote-server-ip = 192.168.1.38
ssh-copy-id root@192.168.1.38
# 3. Connect Remote Server without Password
# ssh root@remote-server-ip, ssh -X user@container_ip XWindows
ssh root@192.168.1.38 # ssh -X root@192.168.1.38

# 3. Go back to the SSH server in the container
vi /etc/ssh/sshd_config # sshd is configured with /etc/ssh/sshd_config

PermitRootLogin yes
# It allows the root user to log in via SSH.
# This is generally considered a security risk, especially in production environments.
PasswordAuthentication yes
# This enables password-based authentication for SSH logins.
# While this is convenient, it is less secure than using key-based authentication,
# which are much more secure and resistant to brute-force attacks.
X11Forwarding yes
# It allows X11 forwarding, enabling graphical applications to be run over SSH.
AllowTcpForwarding yes
# It permits TCP forwarding, which allows SSH connections to tunnel other TCP connections.
X11UseLocalhost no
# This restricts X11 forwarding to connections coming from the localhost. This does not allow machines on your local network to access the X11 forwarding.
# However, if you do want machines on your local network to be able to connect to the X11 forwarding, you can set X11UseLocalhost to no in your sshd_config file.

# Whe you changed the sshd server config file, test the OpenSSH server for errors.
sshd -t
systemctl restart sshd # Restart the OpenSSH service daemon

# On your client:
ssh username@server_ip_address
ssh -X username@server_ip_address # From a machine on your local network, SSH into the server with X11 forwarding enabled
# After logging in, you should be able to run X11 applications, and they will be displayed on your local machine.

Initial Configuration Inside the Arch Container

Next, we need to configure Arch Linux itself, because the base template is minimal and not fully set up for first use.

pct enter 201 # 1. Access the container (Replace 201 with your container’s ID.)

# 2. Initialize the pacman keyring (The Arch template may have an outdated or uninitialized GPG keyring)...
# Initialize and populate the pacman keyring and upgrade the keyring package:
pacman-key --init
pacman-key --populate archlinux
pacman -Sy archlinux-keyring gnupg
pacman-key --refresh-keys

# 3. Full system update.
pacman -Syu --noconfirm

# 4. Arch Linux container run on a kernel that doesn't support landlock, which is a security feature used by pacman 7.0 and later
vi /etc/pacman.conf
DisableSandbox # Uncomment or add this line

# 5. Force a refresh of all package databases:
pacman -Syy
pacman -S --noconfirm reflector
# Update the mirror list using reflector:
reflector --country Spain,France,Germany \
             --latest 20 \
             --protocol http,https \
             --save "/etc/pacman.d/mirrorlist" \
             --sort rate

# Install base development packages and essential tools
pacman -Syu --noconfirm base-devel git

# Install additional tools for productivity
# bc (calculator)
# bat (cat with syntax highlighting)
pacman -S --noconfirm eza zoxide fd bat ripgrep bc

# Install system utilities and help (tldr), fuzzy finder (fzf)
pacman -S --noconfirm fzf wl-clipboard lazygit jq rsync man-db tldr unzip plocate glibc sudo wget curl

# Install system utilities for various tasks
# bpytop (Linux resource monitor), figlet (convert text into ASCII art), cmatrix (an animated matrix in your terminal)
pacman -S --noconfirm fastfetch vim bpytop cmatrix starship figlet fortune-mod

# Install glibc and glibc-locales to support locale generation
pacman -S --noconfirm glibc glibc-locales

# Set up the locale, i.e., the language, numbering, date, and currency formats for your system.
echo "LC_ALL=en_US.UTF-8" >> /etc/environment
echo "LANG=en_US.UTF-8" >> /etc/locale.conf
sed --in-place=.bak 's/^#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/locale.gen
locale-gen en_US.UTF-8

echo 'export BROWSER="firefox" ' >> ~/.zshrc

# Install additional libraries for GUI applications
pacman -S --noconfirm alsa-lib gtk3 libcups libxss libxtst nss ttf-liberation xdg-utils geany

# Set up the keyboard layout: loadkeys es
echo "KEYMAP=es" >> /etc/vconsole.conf

# Create a non-root user named 'nmaximo7' and allow passwordless sudo
useradd -m -G wheel nmaximo7 && \
    echo "nmaximo7 ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

passwd nmaximo7
su nmaximo7
cd

# Clone and install the AUR helper 'yay'
git clone https://aur.archlinux.org/yay-git.git && \
    cd yay-git && \
    makepkg -si --noconfirm

yay -S google-chrome --noconfirm

Snapshots in Proxmox VE

A snapshot is a point-in-time capture of the container’s state. It allows you to rollback (revert) the container to that exact state later.

Proxmox live snapshots are incredibly useful for preserving the state of your virtual machines (VMs) or containers. Think of it like an instant bookmark of the entire container’s filesystem and configuration. By taking a live snapshot, you can preserve the current state of the VM or container’s memory, all configuration settings associated with the VM or container, and the state of all virtual disks at the time of the snapshot. When you encounter issues and you rollback to a snapshot, you restore the VM or container to the exact state it was in when the snapshot was taken, including memory, disk, and settings.

Create a snapshot using the web interface is quite simple. In the Proxmox web interface, select the container the VM or container, go to the Snapshots tab, and click Take Screenshot. In the Create Snapshot dialog box, give it a name (e.g., “initial-configuration”) and a description for the snapshot. Alternatively, you can select the Proxmox node in the server view, click Shell to open a shell in the web interface, type the qm list command to view a list of all VMs on the current Proxmox host (the first column shows the [vmid]), and create a snapshot: qm snapshot [vmid] [snapshot_name] [OPTIONS] (where OPTIONS: ‐‐description ).

If you mess something up, you can rollback to a previously made snapshot. Select the snapshot name and choose Rollback - it will erase any changes made after that snapshot!

You can also delete snapshots you no longer need (to free space). Remember to take snapshots before major system changes, e.g., before a full system update.

Backups in Proxmox VE

Backups produce :an external archive (typically .tar.zst or .tar.gz etc) of your container that you can store separately and restore later.

How to backup a container: In the web UI, select the container and go to Backup. Click Backup Now, choose a Storage (destination), Mode (Snapshot, Suspend, and Stop) and compression type (None, LZO, GZIP, ZSTD). For containers, the default mode is snapshot if supported. If it isn’t possible, it might use stop mode (stops the container during backup) or suspend mode (freezes the container).

The purpose of a backup is to recover from unexpected problems that are not covered by snapshots, such as physical storage failure or entire server failure. Proxmox allows you to schedule backup jobs where you can back up all VMs on all nodes.

How to Schedule a Backup Job in Proxmox VE

To schedule a backup job in ProxMox VE, click the Datacenter node at the top of the Proxmox VE interface, select the Backup tab, and then click Add to create a new backup job.

Configure Backup Settings

To restore a backup, click the backup storage, select a particular backup, and click Restore.

Suspend and Resume After Host Shutdown

Proxmox lacks a native “always boot to this snapshot” feature like VirtualBox,but you can achieve similar results using hibernation:

  1. Before Host Shutdown: qm suspend VMID --todisk to hibernate the VM. This saves the VM’s full state to disk, not just RAM.
  2. After the Proxmox host is back online, type qm resume VMID to restore the VM exactly as it was before suspension from the saved state on disk. This will take longer than resuming from RAM but preserves the VM’s state across host shutdowns.
# Hibernate VM 101 before host shutdown:
qm suspend 101 --todisk

# After reboot, resume VM 101:
qm resume 101

Using the Proxmox VE CLI for Container Management

Proxmox’s web interface is powerful, but knowing the CLI can be very useful for automation, scripting, or when the GUI is broken or unavailable.

The primary CLI tool is pct (Proxmox Container Toolkit), which handles LXC containers​. Navigate to Datacenter, Host (e.g., myserver), and select the Shell tab. Here are some useful command.

pct list # List all containers on the host with their status, IDs, names, IPs, etc.

pct config [pctid] # List the container's configuration.
# It's the same info you'd se in the GUI under Options, like memory, cores, rootfs location, etc.)
root@myserver:~# pct config 201
arch: amd64
cores: 4
features: nesting=1
hostname: archlinux-ct
memory: 1024
net0: name=eth0,bridge=vmbr0,hwaddr=BC:24:11:FF:9B:9F,ip=dhcp,ip6=dhcp,type=veth
ostype: archlinux
parent: archlinux-ct-stable
rootfs: mypool:subvol-201-disk-0,size=64G
swap: 1024
unprivileged: 1

pct start/shutdown/reboot [pctid] # Start/Shutdown/reboot the container pctid
# If the container doesn’t shut down in a timely manner...
pct stop [pctid] # Force-stop (like pulling the power).

pct enter [pctid] # Open a shell in the specified container (exit: exit the container)
# It's equivalent to opening the console in GUI, but via CLI/SSH.

# Executing commands in a container: pct exec  -- command, e.g.,
pct exec 201 -- uname -a
pct exec 201 -- pacman -Syuv --noconfirm

# Changing container settings
pct set [pctid] -onboot 0/1 # Only one hyphen, set the start boot option of the container
pct set [pctid] -memory 2048 # Only one hyphen, set the memory size of the container

pct snapshot [pctid] [name] # Snapshots via CLI

qm list # List all your VMs
qm start [vmid] # Start the VM with ID vmid
qm shutdown [vmid] # Shutdown or stop the VM with ID vmid
qm reboot [vmid] # Reboot the VM with ID vmid
qm reset [vmid] # Reset (not gratefully) the VM with ID vmid
qm stop [vmid] # Stop (not gratefully) the VM with ID vmid
qm config [vmid] # List the VM's settings or options
qm set --onboot 0/1 [vmid] # Set the start boot option of the VM
qm set --memory 2048 [vmid] # Set the memory size of the VM
Bitcoin donation

JustToThePoint Copyright © 2011 - 2025 Anawim. ALL RIGHTS RESERVED. Bilingual e-books, articles, and videos to help your child and your entire family succeed, develop a healthy lifestyle, and have a lot of fun. Social Issues, Join us.

This website uses cookies to improve your navigation experience.
By continuing, you are consenting to our use of cookies, in accordance with our Cookies Policy and Website Terms and Conditions of use.