Raymond P. Burkholder - Things I Do - Virtualization

Frigate Running in Docker inside LXC on Proxmox

nospam@example.com (Raymond P. Burkholder) — Tue, 28 Apr 2026 01:58:50 +0000

Once all the GPU and Docker prerequisites are in place, installing frigate-nve is easy: a) build a yaml file, b) docker compose the file.

In the LXC container, create a frigate directory and move into it:

mkdir frigate
cd frigate

In that directory, here is the content of my docker-compose-yaml file:

services:
  frigate:
    container_name: frigate
    #privileged: true # this may not be necessary for all setups
    restart: unless-stopped
    stop_grace_period: 30s # allow enough time to shut down the various services
    image: ghcr.io/blakeblackshear/frigate:stable
    shm_size: "1512mb" # updated for my camera list based upon error messages in the log
#    devices:
#      - /dev/dri/renderD128:/dev/dri/renderD128 # AMD / Intel GPU, needs to be updated for your hardware
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              #device_ids: ['0'] # this is only needed when using multiple GPUs
              count: 1 # number of GPUs
              capabilities: [gpu]
    volumes:
      - /etc/localtime:/etc/localtime:ro
      - /root/frigate/config:/config
      - /root/frigate/storage:/media/frigate
      - type: tmpfs # 1GB In-memory filesystem for recording segment storage
        target: /tmp/cache
        tmpfs:
          size: 1000000000
    ports:
      - "8971:8971"
      # - "5000:5000" # Internal unauthenticated access. Expose carefully.
      - "8554:8554" # RTSP feeds
      - "8555:8555/tcp" # WebRTC over tcp
      - "8555:8555/udp" # WebRTC over udp
    environment:
      FRIGATE_RTSP_PASSWORD: "xxxxxxx"

Get it started:

# in a foreground process:
docker compose up
# or, as a background process:
docker compose up -d frigate

The login should be seen at something like (or your container's address):

https://127.0.0.1:8971/

Official installation documentation:

Frigage NVR Installation

Docker Notes

nospam@example.com (Raymond P. Burkholder) — Sun, 05 Apr 2026 00:26:37 +0000

Images vs Containers

Docker Image: blueprint with app code and dependencies - static, read-only
Docker Container: running instance of an image - dynamic, executable

Each instruction in the Dockerfile adds an extra layer to the Docker image. Minimize the number of layers by consolidating the instructions to increase the build’s performance and time.

Avoid using multiple RUN commands as it creates multiple cacheable layers which will affect the efficiency of the build process.

Use a single process per container: Each container should run a single process. This makes it easier to manage and monitor containers and helps to keep containers lightweight.

Images can exist without containers, whereas a container needs an image to run. We can create multiple containers from the same image, each with its own unique data and state

Docker commands

Docker Run: It used for launching the containers from images, with specifying the runtime options and commands.
Docker Pull: It fetches the container images from the container registry like Docker Hub to the local machine.
Docker ps: It helps in displaying the running containers along with their important information like container ID, image used and status.
Docker Stop: It helps in halting the running containers gracefully shutting down the processes within them.
Docker Start: It helps in restarting the stopped containers, resuming their operations from the previous state.
Docker Login: It helps to login in to the docker registry enabling the access to private repositories.

Docker network commands:

docker network ls
docker network inspect

Docker image commands:

docker image ls -a
docker container ls -a

Documentation

Dockerfile reference - examples
Dockerfile overview - with example
Command Line Completion
Base images - includes building from scratch
CLI Cheat Sheet
tutorial

NVidia GPU Passthrough to ProxMox LXC Container

nospam@example.com (Raymond P. Burkholder) — Sat, 28 Mar 2026 17:26:45 +0000

How to Enable GPU Passthrough to LXC Containers in Proxmox indicates that the process of providing passthrough of a GPU to both an LXC container as well as a Virtual Machine is not possible as the two types of configurations conflict with each other.

As my own preference is to run whatever possible in LXC containers, I'll summarize the configuration I used, which is an amalgamation of configurations from several sites.

My current installation is ProxMox v9.1.6 with:

ProArt Z890-CREATOR WIFI
Intel(R) Core(TM) Ultra 9 285K
Corsair CMP64GX5M2X6600C32 (128G 4400 MT/s) - ECC would have been nice
NVIDIA Corporation AD103 [GeForce RTX 4070] (rev a1)

In BIOS/UEFI, enable these:

VT-d / IOMMU
Above 4G Decoding
PCIe Native Power Management (if available)

Proxmox kernel parameters:

# /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT="quiet intel_iommu=on iommu=pt pcie_acs_override=downstream,multifunction"

update-grub
reboot

VFIO Binding - optional but recommended:

# /etc/modprobe.d/vfio.conf
options vfio_iommu_type1 allow_unsafe_interrupts=1

Obtain Linux drivers from NVidia. The CUDA toolkit is not required. Only the drivers are required in ProxMox. Toolkits and add-ons are added within the container.

Install the drivers:

apt install build-essential
apt install pve-headers-$(uname -r)
sh NVIDIA-Linux-x86_64-595.58.03.run
# note, use the open kernel, rather than proprietary

Blacklist nouveau:

cat > /etc/modprobe.d/blacklist-nouveau.conf << EOF
blacklist nouveau
options nouveau modeset=0
EOF

Test that the card is accessible:

nvidia-smi

Enable Data Persistence to prevent the GPU from re-initializing with each use.

nvidia-persistenced --persistence-mode
systemctl enable nvidia-persistenced

Then restart:

reboot

Identify the nvidia devices requiring passthrough:

root@host02:~# ls -al /dev/nvidia*
crw-rw-rw- 1 root root 195,   0 Mar 28 11:58 /dev/nvidia0
crw-rw-rw- 1 root root 195, 255 Mar 28 11:58 /dev/nvidiactl
crw-rw-rw- 1 root root 505,   0 Mar 28 11:58 /dev/nvidia-uvm
crw-rw-rw- 1 root root 505,   1 Mar 28 11:58 /dev/nvidia-uvm-tools

/dev/nvidia-caps:
total 0
drwxr-xr-x  2 root root     80 Mar 28 11:58 .
drwxr-xr-x 21 root root   5060 Mar 28 11:58 ..
cr--------  1 root root 508, 1 Mar 28 11:58 nvidia-cap1
cr--r--r--  1 root root 508, 2 Mar 28 11:58 nvidia-cap2

Note the numbers 195, 505 and 508 in this list (yours may be different).

Construct a container, and prior to starting, place the following into /etc/pve/lxc/<vmid>.conf (based upon the device listing above):

dev0: /dev/nvidia0
dev1: /dev/nvidiactl
dev2: /dev/nvidia-modeset
dev3: /dev/nvidia-uvm
dev4: /dev/nvidia-uvm-tools
dev5: /dev/nvidia-caps/nvidia-cap1
dev6: /dev/nvidia-caps/nvidia-cap2

These lines are optional in the config file, one site talks about them by my container seems to work without them (they may be an old style cgroup2 style passthrough rather than the device oriented passthrough above):

lxc.cgroup2.devices.allow: c 195:* rwm
lxc.cgroup2.devices.allow: c 505:* rwm
lxc.cgroup2.devices.allow: c 508:* rwm

Start the container and push the driver file into the container:

pct push <vmid> downloads/NVIDIA-Linux-x86_64-595.58.03.run /root/NVIDIA-Linux-x86_64-595.58.03.run

In the container, install the driver, minus the kernel module:

apt install kmod
sh NVIDIA-Linux-x86_64-595.58.03.run --no-kernel-modules

Run nvidia-smi in the container to confirm the card is reachable.

Add nvtop at the host or the container level to chart live GPU utllization:

apt install nvtop

Additional resources:

Complete GPU passthrough guide for AI workloads, avoid the mistakes I made so you don't have to
[TUTORIAL] NVIDIA drivers instalation Proxmox and CT
How to Enable GPU Passthrough to LXC Containers in Proxmox - contains ollama startup examples with OpenWebUI

Another type of test to run when pytorch is installed:

python -c "import torch; print(torch.cuda.is_available())"

NOTE: for running in unprivileged container, some ideas in Plex GPU transcoding in Docker on LXC on Proxmox v2:

# if you're running in unprivileged mode, you also need to add permissions
# you either add the lines above, or the lines below -- not both
# gid/uid might need to be changed to suit your lxc-setup
dev0: /dev/nvidia0,gid=1000,uid=1000
dev1: /dev/nvidiactl,gid=1000,uid=1000
dev2: /dev/nvidia-modeset,gid=1000,uid=1000
dev3: /dev/nvidia-uvm,gid=1000,uid=1000
dev4: /dev/nvidia-uvm-tools,gid=1000,uid=1000
dev5: /dev/nvidia-caps/nvidia-cap1,gid=1000,uid=1000
dev6: /dev/nvidia-caps/nvidia-cap2,gid=1000,uid=1000
dev7: /dev/dri/card0,gid=1000,uid=1000
dev8: /dev/dri/renderD128,gid=1000,uid=1000

Ensuring nvidia drivers in Proxmox start up prior to containers

nospam@example.com (Raymond P. Burkholder) — Mon, 27 Apr 2026 03:33:14 +0000

From Plex GPU transcoding in Docker on LXC on Proxmox v2:

# make sure that all nvidia devices are loaded upon boot
cat >/etc/systemd/system/nvidia-pre-lxc-init.service <<'EOF'
[Unit]
Description=Initialize NVIDIA devices early (before Proxmox guests)
After=systemd-modules-load.service
Before=pve-guests.service
Wants=pve-guests.service

[Service]
Type=oneshot
RemainAfterExit=yes

ExecStartPre=-/sbin/modprobe nvidia
ExecStartPre=-/sbin/modprobe nvidia_uvm
ExecStart=-/usr/bin/nvidia-smi -L
ExecStart=-/usr/bin/nvidia-modprobe -u -c=0

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable nvidia-pre-lxc-init.service

reboot then try nvidia-smi to confirm function.

Some Tools to Add

nospam@example.com (Raymond P. Burkholder) — Mon, 27 Apr 2026 03:17:03 +0000

Qwen 3.5 9B - general purpose locally run LLM
OctoPrint - web-based 3D printer control software that allows you to remotely control and monitor your 3D printer from a web interface. It was designed to be compatible with a wide range of 3D printers.
Trilium Notes - self-hosted note-taking and personal knowledge management application. It enables users to organize information in a hierarchical tree structure and supports rich text editing, internal linking, images, attachments, and powerful scripting capabilities. This version reflects the most current development efforts under the TriliumNext organization and replaces all prior forks or legacy variants. Trilium is ideal for building personal wikis, structured documentation, and long-term knowledge archives, giving users full local control and privacy.
Vaultwarden - self-hosted password manager which provides secure and encrypted password storage. It uses client-side encryption and provides access to passwords through a web interface and mobile apps.
NetBox - the source of truth for everything on your network, from physical components like power systems and cabling to virtual assets like IP addresses and VLANs. Network automation and observability tools depend on NetBox’s authoritative data to roll out configurations, monitor changes, and accelerate operations across the enterprise

NUT UPS USB Connected to Proxmox Unprivileged LXC

nospam@example.com (Raymond P. Burkholder) — Sat, 25 Apr 2026 22:07:41 +0000

Taking RTL_433 in unprivileged LXC container, with automatic device path change for inspiration, I was able to connect multiple APC and Eaton UPS USB cables to a server with the following mechanism. I forwarded the USB connections into an LXC container as I use my nut2mqtt - Communication between Network UPS Tools (NUT) and MQTT for monitoring.

The Proxmox host is configured in a standard way using the primary UPS USB connection (still yet to try).

As a USB cable is inserted, "journalctl -f" will log information similar to:

Apr 25 15:48:21 host02 kernel: usb 3-4: new full-speed USB device number 10 using xhci_hcd
Apr 25 15:48:21 host02 kernel: usb 3-4: New USB device found, idVendor=051d, idProduct=0002, bcdDevice= 0.90
Apr 25 15:48:21 host02 kernel: usb 3-4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Apr 25 15:48:21 host02 kernel: usb 3-4: Product: Back-UPS XS 1300G FW:864.L6 .D USB FW:L6
Apr 25 15:48:21 host02 kernel: usb 3-4: Manufacturer: American Power Conversion
Apr 25 15:48:21 host02 kernel: usb 3-4: SerialNumber: 4B12P636
Apr 25 15:48:21 host02 kernel: hid-generic 0003:051D:0002.0007: hiddev3,hidraw5: ......

Use "lsusb" to determine the bus and device assignment based upon the 'idVendor' and 'idProduct' assignments above:

# lsusb -d 051d:0002
Bus 003 Device 010: ID 051d:0002 American Power Conversion Uninterruptible Power Supply

Thus you'll see an associated entry in /dev:

~# ls -altr /dev/bus/usb/003/010
crw-rw-rw- 1 root root 189, 265 Apr 25 15:48 /dev/bus/usb/003/010

Note the cgroup2 '189, 265' identifiers. Adding an entry to your /etc/pve/lxc/<lxc-id>.conf entry will be required:

lxc.cgroup2.devices.allow: c 189:* rwm

Whenever the USB cable is plugged in, a different device may be constructed. To pass that information to Proxmox for when it starts the container, use something like:

# cat /etc/udev/rules.d/50-ups-usb.rules
SUBSYSTEM=="usb", ENV{ID_VENDOR_ID}=="051d", ENV{ID_MODEL_ID}=="0002", ENV{ID_SERIAL_SHORT}=="4B12P636", MODE="0666", RUN="/usr/sbin/pct set <lxc-id> --dev0 mode=0666,path=$devnode"

If the file is changed, it can be processed with:

# reload rules and rerun
udevadm control --reload-rules
udevadm trigger
# optional cable test simulation
udevadm test /dev/bus/usb/003/010

The ENV{ID_VENDOR_ID}, ENV{ID_MODEL_ID} & ENV{ID_SERIAL_SHORT} variable names and content can be confirmed with:

# udevadm info  /dev/bus/usb/003/010
P: /devices/pci0000:80/0000:80:14.0/usb3/3-4
M: 3-4
R: 4
J: c189:265
U: usb
T: usb_device
D: c 189:265
N: bus/usb/003/010
L: 0
V: usb
E: DEVPATH=/devices/pci0000:80/0000:80:14.0/usb3/3-4
E: DEVNAME=/dev/bus/usb/003/010
E: DEVTYPE=usb_device
E: DRIVER=usb
E: PRODUCT=51d/2/90
E: TYPE=0/0/0
E: BUSNUM=003
E: DEVNUM=010
E: MAJOR=189
E: MINOR=265
E: SUBSYSTEM=usb
E: USEC_INITIALIZED=2435707957355
E: ID_BUS=usb
E: ID_MODEL=Back-UPS_XS_1300G_FW:864.L6_.D_USB_FW:L6
E: ID_MODEL_ENC=Back-UPS\x20XS\x201300G\x20FW:864.L6\x20.D\x20USB\x20FW:L6\x20
E: ID_MODEL_ID=0002
E: ID_SERIAL=American_Power_Conversion_Back-UPS_XS_1300G_FW:864.L6_.D_USB_FW:L6_4B1233P63346
E: ID_SERIAL_SHORT=4B12P636
E: ID_VENDOR=American_Power_Conversion
E: ID_VENDOR_ENC=American\x20Power\x20Conversion
E: ID_VENDOR_ID=051d
E: ID_REVISION=0090
E: ID_USB_MODEL=Back-UPS_XS_1300G_FW:864.L6_.D_USB_FW:L6
E: ID_USB_MODEL_ENC=Back-UPS\x20XS\x201300G\x20FW:864.L6\x20.D\x20USB\x20FW:L6\x20
E: ID_USB_MODEL_ID=0002
E: ID_USB_SERIAL=American_Power_Conversion_Back-UPS_XS_1300G_FW:864.L6_.D_USB_FW:L6_4B1233P63346
E: ID_USB_SERIAL_SHORT=4B12P636
E: ID_USB_VENDOR=American_Power_Conversion
E: ID_USB_VENDOR_ENC=American\x20Power\x20Conversion
E: ID_USB_VENDOR_ID=051d
E: ID_USB_REVISION=0090
E: ID_USB_INTERFACES=:030000:
E: ID_VENDOR_FROM_DATABASE=American Power Conversion
E: ID_MODEL_FROM_DATABASE=Uninterruptible Power Supply
E: ID_PATH_WITH_USB_REVISION=pci-0000:80:14.0-usbv2-0:4
E: ID_PATH=pci-0000:80:14.0-usb-0:4
E: ID_PATH_TAG=pci-0000_80_14_0-usb-0_4
E: ID_FOR_SEAT=usb-pci-0000_80_14_0-usb-0_4
E: TAGS=:seat:
E: CURRENT_TAGS=:seat:

Resources:

udev(7) — Linux manual page - Dynamic device management
Persistent names for USB-serial devices in Linux (/dev/ttyUSBx -> /dev/custom-name) - I first looked at doing symlinks, but realized it is not required if I can perform a 'pct set' directly on the container configuration.

LXC Fresh Container Construction From Scratch for Proxmox

nospam@example.com (Raymond P. Burkholder) — Fri, 27 Feb 2026 21:03:19 +0000

There are many articles available which discuss customizing a pre-existing Proxmox Container Template. Few, if any, discuss constructing an LXC container from scratch. Maybe because, fundamentally, a container template is just the rootfs as tarball, so building it is quite easy:

Build a linux based virtual machine, I use Debian's recent release
Install LXC and its template package
Construct and initialize an LXC container
Shut it down and and zip it up
Copy it over to the ProxMox template directory

The details:

# build the linux vm - details not relevant here
# ssh into the vm, or start a command line
# install basic packages

sudo apt install --no-install-recommends lxc lxc-templates xz-utils bridge-utils wget debootstrap rsync

# basic container templates are in:
#   /usr/share/lxc/templates/ 
# for debian as well as other distributions

# create an lxc container, provide a list any additional packages

lxc-create --template debian --name trixie-template -- --release trixie --packages iputils-ping,vim-tiny

# start and attach to the container
lxc-start trixie-template
lxc-attach trixie-template

# prepare for generating template
apt clean
apt purge

# Remove SSH host keys to ensure unique keys for each clone:
rm /etc/ssh/ssh_host_*

# Empty the machine ID file:
truncate -s 0 /etc/machine-id

# clear history
unset HISTFILE
# truncate history
history -c
> ~/.bash_history
# the following has a space in front to prevent inclusion in the history
 shutdown -h now

# the shutdown returns to the virtual machine's prompt
# compress the directory structure

cd /var/lib/lxc/trixie-template/

# remove /dev files as they can't be created in an unprivileged container
# an example error message if not removed:
#   tar: ./rootfs/dev/urandom: Cannot mknod: Operation not permitted
# construction of a new container will re-create the directory and files

rm ./rootfs/dev/ptmx
rm ./rootfs/dev/zero
rm ./rootfs/dev/tty3
rm ./rootfs/dev/urandom
rm ./rootfs/dev/null
rm ./rootfs/dev/tty
rm ./rootfs/dev/console
rm ./rootfs/dev/tty4
rm ./rootfs/dev/tty2
rm ./rootfs/dev/random
rm ./rootfs/dev/tty1
rm ./rootfs/dev/full

# cd into rootfs and zip the container

cd rootfs
tar --xz --acls --numeric-owner -cf /var/local/trixie-13-3-template.tar.xz ./

# the xz file can be copied over to proxmox and placed into
# /var/lib/pve/local-btrfs/template/cache/
# for use as a template for container creation

During the first use of lxc-create to create the original container, packages are downloaded and installed to build the container. The packages and installation is cached for faster subsequent builds of the same container type.

If the cache becomes stale, it can be rebuilt by using --flush-cache in a manner similar to:

lxc-create --template debian --name trixie-template -- --release trixie --flush-cache --packages iputils-ping,vim-tiny,less,python-minimal

An existing cache can be updated with something like:

sudo chroot /var/cache/lxc/debian/rootfs-trixie-amd64
apt-get update
apt-get dist-upgrade
apt-get clean
exit

courtesy of Updating lxc image/container caches

One other note, there are two package candidates for installing the ping utility:

iputils-ping - native Linux ping, preferred for Debian/Linux
inetutils-ping - general gnu version, used on a variety of posix sytstems, less preferred

Some fix-ups in the process:

apt-get install less
dpkg-reconfigure locales
useradd user

Docker Installation In LXC on ProxMox

nospam@example.com (Raymond P. Burkholder) — Sun, 29 Mar 2026 17:26:11 +0000

First of all, the obligatory caveat from 2023: where Proxmox developers discourage running Docker in LXC. Upgrades to Proxmox may break 'something', which will require remediation of the containers. The relationship between Proxmox, LXC and Docker is brittle.

I do totally agree not to install Docker directly on the Proxmox host, as Docker will conflict with many networking and functional operations.

However, the combination of Docker in LXC is just too enticing. What other mechanism is available to compartmentalize applications and provide GPU resources to each compartmentalized application, particularly when an application is packaged as a Docker container, without recourse for building a native LXC container of the application? Putting LXC and Docker into a VM seems a bit 'heavy' just for the sake of softening some brittleness. All the same management has to take place within the VM.

The key benefit is that devices such as one or more GPUs can be passed through to multiple LXC containers plus any nested docker containers. Otherwise, in the scenario where the GPU or PCIe device is passed through to a VM, as far as I know, it has to be dedicated to the VM. I've read that the devices can not be shared between a VM and LXC containers due to configuration differences between VM pass-through and LXC pass-through.

Given the caveat, I'll see if I can make this work. Not so easy. Trying to run

docker run --rm hello-world

Yields an error:

docker: Error response from daemon: failed to mount /tmp/containerd-mount2030888385: 
mount source: "overlay", target: "/tmp/containerd-mount2030888385", 
fstype: overlay, flags: 0, 
data: "
  workdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/3/work,
  upperdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/3/fs,
  lowerdir=/var/lib/containerd/io.containerd.snapshotter.v1.overlayfs/snapshots/2/fs,userxattr", 
  err: permission denied

With an associated apparmor error in Proxmox:

audit: type=1400 audit(1774803476.655:145): 
  apparmor="DENIED" operation="mount" class="mount" info="failed perms check" error=-13 
  profile="lxc-131_" 
  name="/tmp/containerd-mount2030888385/" 
  pid=1480790 comm="dockerd" fstype="overlay" srcname="overlay"

The simple solution is to set nesting=1 in the proxmox lxc options.

The next hurdle is that it may take a couple/several minutes for the Docker file to run when the container starts up. If so, you may see this:

> ps aux
root      41  0.0  0.0   2680  1808 ?    Ss   20:09   0:00 /bin/sh /usr/lib/ifupdown/wait-online.sh

If so, this can be disabled:

systemctl disable ifupdown-wait-online.service

In addition, systemd-networkd-wait-online may be waiting for an interface it doesn't manage. This will cause a startup delay of several minutes. Use the following to add some debugging and logging

systemctl edit systemd-networkd-wait-online.service

[Service]
Environment=SYSTEMD_LOG_LEVEL=debug

In my case, I then saw something like:

root@frigate01:~# systemctl status systemd-networkd-wait-online.service
● systemd-networkd-wait-online.service - Wait for Network to be Configured

Mar 29 20:38:44 frigate01 systemd-networkd-wait-online[97]: lo: link is ignored
Mar 29 20:38:44 frigate01 systemd-networkd-wait-online[97]: vlan60: link is not managed by networkd.

I have used a non-standard interface name. I resolved this by updating the edit with the following:

> systemctl edit systemd-networkd-wait-online.service

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --interface=vlan60
#Environment=SYSTEMD_LOG_LEVEL=debug

The empty ExecStart line clears the original command parameters.

Some Docker commands:

docker run --rm -it hello-world bash

Docker Installation

nospam@example.com (Raymond P. Burkholder) — Sun, 29 Mar 2026 15:32:27 +0000

Docker installation is easy enough:

curl -fsSL https://get.docker.com -o get-docker.sh
sh get-docker.sh

This installs the latest stable release of:

Docker CLI,
Docker Engine,
Docker Buildx,
Docker Compose,
containerd, and
runc.

To get an idea of usage:

sh -c docker version

lxc-create of debian testing on debian trixie

nospam@example.com (Raymond P. Burkholder) — Tue, 17 Mar 2026 03:10:34 +0000

When creating a Debian testing/forky LXC container on a Debian trixie machine, the following error may be encountered in the output:

I: Resolving dependencies of required packages...
I: Resolving dependencies of base packages...
I: Checking component main on http://deb.debian.org/debian...
E: Couldn't find these debs: isc-dhcp-client
Failed to download the rootfs, aborting.
Failed to download 'debian base'
failed to install debian

This is a result of bug #1125011 in the Debian bug tracker.

There are several possible solutions:

Manually apply the patches supplied by the Debian LXC team
Probably might be solved by running lxc-create on a testing/forky machine, where the solution may have already been applied - I have not confirmed this
Or it may work on a sid machine

Opening ProxMox .vv files with virt-viewer (Debian & Firefox)

nospam@example.com (Raymond P. Burkholder) — Sat, 14 Mar 2026 22:54:52 +0000

If running Firefox on a Debian Linux machine, install virt-viewer:

sudo apt install virt-viewer

Ensure the VirtIO drivers and such have been installed in the virtual machine (if Windows) in order to provide SPICE services.

Then, in Firefox on your workstation:

go into about:config, and add the key 'network.protocol-handler.expose.virt-viewer' as boolean and set to true
go into about:preferences, and set "What should Firefox do with other files" to "Ask whether to open or save files".
in Proxmox, open a SPICE based console for a virtual machine, which attempts a download or a run of a customized .vv file,
Firefox will then request to open a Virt-Viewer file with Remote Viewer - at this point, you can set it as the default viewer, and it will show up in the application preferences

apparmor="DENIED" operation="mount" class="mount" info="failed perms check" error=-13

nospam@example.com (Raymond P. Burkholder) — Sat, 28 Feb 2026 23:51:54 +0000

After following my own instructions for building my own LXC container template for ProxMox using the SID release, when the container started, the ProxMox logs would fill up with errors along the lines of:

apparmor="DENIED" operation="mount" class="mount" info="failed flags match" error=-13 name="/run/credentials/systemd-journald.service/" flags="rw, move"

My Trixie template did not seem to offer up these types of errors. LXC containers were created with the 'Unpriviledged Container" setting to 1|yes.

Instead of going the last resort brute force and ignorance route of using the following configuration (see Fixing net.ipv4.ip_unprivileged_port_start and AppArmor Docker Errors in a Proxmox LXC for some background):

lxc.apparmor.profile: unconfined
features: keyctl=1,nesting=1

I took a more nuanced/detailed approach. AppArmor Denied Operation mount info failed flags match Error 13 provided a starting point for developing a solution.

After incrementally adding rules as new Apparmor DENIED statements occurred, this is the rule set which seems to resolve the errors. Once the container is created, these are the rules I add to the end of /etc/pve/lxc/<vmid>.conf:

lxc.apparmor.raw: mount options=(rw,move) -> /run/credentials/{,**},
lxc.apparmor.raw: mount options=(ro, remount, noatime, bind) -> /,
lxc.apparmor.raw: mount options=(ro, remount, bind) -> /dev/,
lxc.apparmor.raw: mount options=(rw, move) -> /dev/mqueue/,
lxc.apparmor.raw: mount options=(rw, move) -> /tmp/,
lxc.apparmor.raw: mount options=(rw, move) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /run/systemd/mount-rootfs/run/credentials/systemd-networkd.service/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/sys/net/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/uptime,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/slabinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/meminfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/swaps,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/loadavg,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/cpuinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/diskstats,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/stat,
lxc.apparmor.raw: userns create,

Restart the container, and the errors should no longer occur.

Don't try to place statements in /var/lib/lxc/<vmid>/config as it is over-written by ProxMox upon container startup. Rules are appended to that configuration.

I used the following for a trixie v13.3 version of a container:

lxc.apparmor.raw: mount fstype=ramfs -> /dev/shm/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /dev/shm/,
lxc.apparmor.raw: mount options=(ro, remount, bind) -> /dev/,
lxc.apparmor.raw: mount options=(rw, move) -> /dev/mqueue/,
lxc.apparmor.raw: mount options=(rw, move) -> /run/lock/,
lxc.apparmor.raw: mount options=(rw, move) -> /tmp/,
lxc.apparmor.raw: mount options=(ro, remount, noatime, bind) -> /,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec, remount, nosymfollow, bind) -> /run/systemd/mount-rootfs/run/credentials/systemd-networkd.service/,
lxc.apparmor.raw: userns create,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /run/systemd/namespace-{,**},
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/sys/net/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/uptime,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/slabinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/meminfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/swaps,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/loadavg,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/cpuinfo,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/diskstats,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec, remount, bind) -> /run/systemd/mount-rootfs/proc/stat,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /run/systemd/unit-root/proc/,
lxc.apparmor.raw: mount options=(ro, nosuid, nodev, noexec) -> /sys/kernel/config/,
lxc.apparmor.raw: mount options=(rw, nosuid, nodev, noexec) -> /sys/kernel/config/,

Sample Proxmox command to build LXC container from Template

nospam@example.com (Raymond P. Burkholder) — Sat, 28 Feb 2026 04:40:48 +0000

pct_id=101
pct_name=test01
pct create $pct_id /var/lib/pve/local-btrfs/template/cache/trixie-13-3-template.tar.xz  \
  -hostname $pct_name \
  -description 'demo build' \
  -onboot 1 \
  -startup up=3 \
  -ostype debian \
  -arch amd64 \
  -cores 2 \
  -memory 1024 \
  -nameserver 10.10.10.10 -searchdomain 'example.com' \
  -net0 name=vlan30,bridge=vmbr1,ip=dhcp,tag=30,type=veth \
  -rootfs local-btrfs:8,mountoptions="noatime;discard" \
  -swap 512

Migrating LXC Containers From One Machine To Another

nospam@example.com (Raymond P. Burkholder) — Wed, 04 Apr 2018 15:39:24 +0000

For some machines with LXC containers, they have been running for a number of years. I want to take the easy way out and move the containers from one physical machine to another. At another time, I will rebuild the containers.

Since I am running BTRFS subvolumes for each container, I could be using BTRFS snapshot/send/receive commands to migrate/copy/replicate subvolumes. But before attempting that, I wanted to give the 'copy' a try. To do this properly, at the source, use the following -- with numeric-owner being a required paramenter -- command to collect the files:

tar --numeric-owner -czvf mycontainer.tar.gz /var/lib/lxc/my_container

At the destination, expand that file out:

tar --numeric-owner -xzvf mycontainer.tar.gz -C /var/lib/lxc/

The lxc users mailing list and Stack OverFlow were helpful.

Other stuff to do:

Read up on CGroups in the Linux Programmer's Manual

In migrating from a very old version of LXC to a much newer version of LXC, I was getting errors. I needed to run a some debug to get a handle on errors:

lxc-start -n container -F --logpriority=DEBUG --logfile log

I had errors along the lines of:

Activating lvm and md swap...done.
Checking file systems...Segmentation fault (core dumped)
failed (code 139).

ServerFault had the solution: put "vsyscall=emulate" into /etc/default/grub, run 'update-grub' and reboot. Looks like I need to modernize my containers so I can eliminate this workaround, which may have some security considerations. There is a Debian Bug for this.

einstein home has a blog with some kernel references to the issue, in effect saying: "vsyscall is now disabled on latest linux distros". A lengthier LWN article at On vsyscalls and the vDSO. This works with kernel 4.14, my current version, but I see somewhere else that the workaround is entirely removed in kernel 4.15, at least in the Arch world. At bug 847154: "This breaks (e)glibc 2.13 and earlier".

Note, see newer notes at LXC Fresh Container Construction From Scratch for Proxmox.