LXC on Zwindler's Reflection

Les artefacts OCI comme base de machines LXC sur Proxmox 9.1, enfin ?

Mon, 24 Nov 2025 18:00:00 +0200

Contexte

Il y a quelques jours, la dev team de Proxmox VE a annoncé une nouvelle version (la 9.1) dont la nouvelle fonctionnalité majeure est l’ajout du support des artefacts OCI comme base pour créer des containers LXC.

Une fonctionnalité attendue depuis TREEEEES longtemps, puisqu’en théorie cela ouvre enfin la porte au lancement de containers de type “Docker” dans Proxmox, ce que les devs de Proxmox avaient toujours refusé.

C’est d’ailleurs la raison pour laquelle un de mes articles de blog cartonne le plus sur Google (snif, bientôt la fin de la gloire) :

Cet article où j’explique comment lancer des containers Docker (via LXC) dans Proxmox VE (normalement pas possible)

Create LXC containers from OCI images

Proxmox VE 9.1 integrates support for Open Container Initiative (OCI) images, a standard format for container distribution. Users can now download widely-adopted OCI images directly from registries or upload them manually to use as templates for LXC containers. Depending on the image, these containers are provisioned as full system containers or lean application containers.

On teste ? D’abord les prérequis

Du coup, je suis curieux, comment ça fonctionne ?

D’abord, il faut aller pré-télécharger l’image qui vous intéresse dans votre stockage (pouvant accueillir des “CT Templates”).

Truc fun, il y a un bouton qui s’appelle “Query tags”, qui j’imagine permet de récupérer une liste des tags. Bon ben, ça commence mal, ça ne fonctionne pas (en tout cas pas sur docker.io…).

command 'skopeo list-tags docker://docker.io/zwindler/prime-calculator' failed: exit code 1 (500)

EDIT : depuis, ça refonctionne, sur tous mes nodes. Peut être un problème temporaire

Note : skopeo c’est justement une des dépendances utilisées dans mon article “hack proxmox+docker” et qui permet de manipuler (télécharger surtout) des containers depuis des registries distantes.

Création du container LXC

Maintenant que le template (l’image OCI) est disponible sur notre stockage, on peut créer un container LXC comme d’habitude. On clique sur “Create CT”, on donne un CT ID, un password :

Pour le template, on choisit notre artefact OCI :

Et on valide. Proxmox devrait créer notre container :

Même si le terminal nous indique que les containers applicatifs peuvent ne pas bien fonctionner dans la console JS, pour tous les containers que j’ai réussi à démarrer (cf la suite), j’ai toujours eu une console fonctionnelle.

Le pari a l’air donc plutôt réussi.

Exemple avec docker.io/python:3.11.14-trixie

Quand ça ne marchait pas (encore)

J’ai eu 2 soucis sur un proxmox VE 91 (qui avait été mis à jour et un peu bidouillé, bref, une machine qui avait vécue) pour démarrer un container LXC sur base OCI avec Proxmox VE 9.1 car je suis tombé sur 2 bugs.

Je n’ai pas reproduit ces bugs sur une installe “fraiche”.

Premier bug : image “from scratch”

D’abord, mon image prime-calculator n’est même pas créée.

TASK ERROR: unable to create CT 106 - Error while extracting OCI image: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids: Unknown layer digest sha256:2bc4d17e1eb16f6b52acbafeb6d86c8f3eaf9588a5e2a7a245b6bb1d85e93396 found in rootfs.diff_ids

Bon, admettons. Mon image, c’est un binaire “from scratch”, sans rien à part le binaire, et je me suis peut-être trompé quelque part…

Ca ne marche toujours pas.

Deuxième bug : impossible de démarrer

Cependant, même avec des images connues, le container est bien créé :

Mais impossible de le démarrer :

problem with monitor socket, but continuing anyway: got timeout
TASK ERROR: unable to get PID for CT 105 (not running?)

Même erreur avec la ligne de commande

pct start 105 --debug
problem with monitor socket, but continuing anyway: got timeout
lxc_start_main: 257 Container is already running
- Read uid map: type u nsid 0 hostid 100000 range 65536
INFO confile - ../src/lxc/confile.c:set_config_idmaps:2295 - Read uid map: type g nsid 0 hostid 100000 range 65536
ERROR lxc_start - ../src/lxc/tools/lxc_start.c:lxc_start_main:257 - Container is already running
unable to get PID for CT 105 (not running?)

Après investigation (laborieuse), il se trouve que c’est un problème AppArmor. Je ne sais pas si c’est moi qui l’ai causé avec mes bidouilles ou si c’est un bug plus généralisé pour l’instant (probablement l’option 1, mais 2 n’est pas impossible non plus…)

Nov 23 10:37:26 node01 systemd[1]: Started pve-container-debug@105.service - PVE LXC Container: 151.
Nov 23 10:37:27 node01 kernel: audit: type=1400 audit(1764067047.008:175): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 node01 kernel: audit: type=1400 audit(1764067047.008:176): apparmor="DENIED" operation="create" class="net"
Nov 23 10:37:27 node01 systemd[1]: pve-container-debug@105.service: Deactivated successfully.
Nov 23 10:37:37 node01 pct[21369]: unable to get PID for CT 105 (not running?)

Le workaround temporaire (et cracra) est de désactiver le profil appArmor pour lxc-start, et supprimer les éventuels fichiers / process zombies.

apparmor_parser -R /etc/apparmor.d/usr.bin.lxc-start

ps aux | grep "lxc-start" | grep "105" | awk '{print $2}' | xargs -r kill -9
rm -f /var/lib/lxc/105/config.lock
rm -f /run/lxc/lock/var/lib/lxc/105

Note : On peut aussi le désactiver de manière permanente, mais c’est évidemment quelque chose à ne pas faire.

À partir de là, le container est accessible, parfois en console (ça dépend du container)

Conclusion

A priori, les problèmes que j’ai rencontré ne se reproduisent pas sur une “fresh install”. C’est donc probablement un souci lié à mes “vieilles” machines.

En bonus, un autre article en anglais qui m’a fait persévérer quand j’ai compris que ça marchait chez certains :

blog Raymii.org - Finally, run Docker containers natively in Proxmox 9.1 (OCI images)

Note : l’article m’a permis de redécouvrir la commande pct enter CTID qui permet de se logger au container.

En attendant, vous avez toujours mon hack ;-)

Transformer Proxmox VE en node Kubernetes avec LXC et lxcri

Mon, 17 Nov 2025 18:00:00 +0200

Il ne savait pas que c’était complètement stupide, alors il l’a fait

Quel mensonge… Bien sûr, je sais très bien que c’est débile. Raison pour laquelle cette idée est donc irrésistible.

Si vous suivez le blog, vous savez que j’utilise beaucoup Proxmox VE (les articles qui attirent le plus sur le blog sont d’ailleurs des articles sur cette technologie de virtualisation).

Proxmox VE, c’est très cool ; on peut faire des VMs (QEMU) avec, mais aussi, si on n’a pas de VT-x ou qu’on veut des “lightweight VMs” (terme dont on a abusé à outrance), on peut installer des OS complets dans des containers avec LXC.

Mais au delà de ces deux solutions, les devs du projet Proxmox VE sont assez rigides (et pas que là dessus). C’est d’ailleurs pour ça que j’ai posté quelques “hacks” pour contourner les limitations de Proxmox, notamment cet article où j’explique comment lancer des containers Docker (via LXC) dans Proxmox VE (normalement pas possible).

Et si on allait encore plus loin dans le hack idiot ?

Et si, non seulement on exécutait des containers OCI dans Proxmox VE, mais qu’EN PLUS, on transformait nos hôtes Proxmox VE en ✨️ Nodes Kubernetes ✨️ ???

On s’y prend comment ?

Le but n’est évidemment pas d’installer Kubernetes à côté de Proxmox VE, mais réutiliser le plus de choses possibles. Typiquement, je vais réutiliser la techno de “virtu”.

Proxmox VE supportant 2 technos de virtualisation différentes (qemu et LXC), il faut choisir. Et comme j’aime bien LXC et que j’ai déjà expérimenté sur le hack Docker => LXC sur Proxmox VE, la question était vite répondue.

Toute la difficulté de l’exercice est de trouver comment rendre LXC “CRI-compatible”. Et on a de la chance, Linux Containers, la fondation qui chapeaute LXC et Incus (ex LXD, “refermé” par Canonical), a écrit il y a quelques années un CRI pour LXC appelé lxcri. Et bien sûr, comme c’est un projet à l’utilité discutable, le truc n’est plus maintenu depuis 2021.

J’avais d’ailleurs essayé de l’utiliser, passé pas mal de temps dessus en février 2024 (j’ai essuyé bug sur bug, suis passé par des forks, …) pour échouer lamentablement sur un problème de compatibilité avec ma version de LXC (5+ sous Proxmox 8, 6 en Proxmox 9), entre autres bugs.

lxcri is a wrapper around LXC which can be used as a drop-in container runtime replacement for use by CRI-O.

On va donc quand même avoir besoin de 3 trucs en plus sur notre serveur Proxmox pour que mon idée débile fonctionne :

lxcri comme container runtime de base niveau
cri-o comme container runtime de haut niveau
kubelet pour piloter le runtime et communiquer avec le control plane

C’est parti

OK. lxcri s’appuie donc sur cri-o, le container runtime de Red Hat. On commence donc par installer cri-o :

https://github.com/cri-o/cri-o/blob/main/install.md

Note : mon serveur Proxmox VE 8 de l’époque utilisait Debian 12 comme OS de base. On devrait donc se baser là-dessus pour la variable $OS (comme l’indique la doc). Cependant, à l’heure où j’ai testé la première fois, les dépôts de CRI-O étaient en cours de migration, avec une documentation pas à jour et des releases manquantes. Le répo download.opensuse.org/repositories/devel:/kubic:/libcontainers:/stable:/cri-o n’avait pas le PATH Debian_12, ni la version 1.29 de Kubernetes… J’avais BIEN ragé.

On ne devrait plus avoir de soucis maintenant :

export KUBERNETES_VERSION=v1.32
export CRIO_VERSION=v1.32

# créer un répertoire pour les keyrings (il n'existe pas toujours sur une install fraiche)
sudo mkdir -p /usr/share/keyrings

# répo de kubernetes
curl -fsSL https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/Release.key | sudo gpg --dearmor -o /etc/apt/keyrings/kubernetes-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/kubernetes-apt-keyring.gpg] https://pkgs.k8s.io/core:/stable:/$KUBERNETES_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/kubernetes.list

# répo de crio
curl -fsSL https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/Release.key |
 sudo gpg --dearmor -o /etc/apt/keyrings/cri-o-apt-keyring.gpg

echo "deb [signed-by=/etc/apt/keyrings/cri-o-apt-keyring.gpg] https://download.opensuse.org/repositories/isv:/cri-o:/stable:/$CRIO_VERSION/deb/ /" |
 sudo tee /etc/apt/sources.list.d/cri-o.list

sudo apt update
sudo apt install cri-o

A partir de là, on a cri-o. On pourrait le configurer mais si on fait ça, il utilisera runc et on n’utiliserait pas LXC en tant que runtime.

Ce n’est pas le but de ce hack !

C’est donc à ce moment là qu’on rebascule sur la documentation de lxcri :

github.com/lxc/lxcri

Ya pas de release

Et oui… il faut préalablement builder le binaire lxcri et le déposer dans le /usr/local de notre serveur Proxmox VE. Il n’y a pas de binaire précompilé dans le projet, c’est une issue ouverte juste avant qu’il ne soit abandonné 😬😬.

Et pour que ce soit encore plus fun, le processus de build passe par un Dockerfile, ce qui est rigolo puisqu’on n’a pas Docker sur notre node Proxmox…

J’ai donc essayé de builder lxcri depuis une machine avec Docker, en suivant la commande indiquée sur le GitHub. Patatra. (Déjà, il manque un “.” en fin de commande docker build dans la doc) ça fail misérablement à la compilation…

Note : je n’ai plus l’erreur en question, probablement un problème de dépendances. C’est relou parce qu’on va devoir faire plein de choses à la main… Mais ne vous embêtez pas à git clone, on va partir sur un fork (d’un fork).

En allant jeter un œil au Dockerfile, on se rend vite compte qu’on ne fait que lancer un script (install.sh)…

Quand on appelle Docker avec le buildarg installcmd=install_runtime, on lance la fonction install_runtime, qui appelle install_runtime_noclean, qui lance add_lxc puis add_lxcri.

Je veux juste compiler lxc (pour les bindings) et lxcri. Je vais donc le faire à la main. Pour ça, il faut golang 1.16 (ça date…).

Il y a pas mal de code pété un peu partout et plusieurs issues ouvertes dans lesquelles les mainteneurs conseillent de partir sur un fork :

https://github.com/drachenfels-de/lxcri

J’ai passé pas mal de temps à le débugger, et au final j’ai fait mon propre fork (https://github.com/zwindler/lxcri), qui nécessite golang 1.22+ et qui ajoute un gros paquet de fixes.

Prérequis pour builder lxcri

On va installer un paquet de trucs :

sudo apt update
sudo apt install curl git meson pkg-config cmake libdbus-1-dev docbook2x

On installe Golang si on ne l’a pas (peu de chance que vous ayez Golang sur un node Proxmox VE) :

wget https://go.dev/dl/go1.25.4.linux-amd64.tar.gz
sudo rm -rf /usr/local/go && sudo tar -C /usr/local -xzf go1.25.4.linux-amd64.tar.gz
export PATH=$PATH:/usr/local/go/bin
go version
 go version go1.25.4 linux/amd64

Je vais aussi devoir récupérer et compiler lxc. Pendant un moment, j’étais bloqué sur la version 4.0.12 (très précisément) car la 4.0.6 qu’on trouve sur Debian 11 ne fonctionne pas avec le code de lxcri (j’ai mangé plein de bugs).

Mais la bonne nouvelle, c’est que comme je suis un try-harder de l’espace, à force de fixes sur mon fork, celui-ci fonctionne avec la dernière version de lxc (6.x), ce qui tombe bien parce que c’est la version sur mon Proxmox VE 9 à jour.

git clone https://github.com/lxc/lxc
cd lxc

meson setup -Dprefix=/usr -Dsystemd-unitdir=PATH build
 Build targets in project: 30

 lxc 6.0.0

 User defined options
 prefix : /usr
 systemd-unitdir: PATH

 Found ninja-1.12.1 at /usr/bin/ninja

meson compile -C build
 INFO: autodetecting backend as ninja
 INFO: calculating backend command to run: /usr/bin/ninja -C /root/lxc/build
 ninja: Entering directory `/root/lxc/build'
 [544/544] Linking target src/lxc/tools/lxc-monitor

Ça a buildé plein de trucs, c’est cool. Mais les fichiers qui m’intéressent sont ici :

find . -name "lxc.pc"
./build/meson-private/lxc.pc

ls build/*lxc*
build/liblxc.so build/liblxc.so.1 build/liblxc.so.1.8.0 build/lxc.spec

build/liblxc.so.1.8.0.p:
liblxc.so.1.8.0.symbols

Je mets ça aux bons endroits dans mon Proxmox VE avec un :

sudo make install
sudo ldconfig

Builder comme jamais

Ok, c’est parti pour jouer avec mon fork :

git clone https://github.com/zwindler/lxcri.git lxcri.zwindler
cd lxcri.zwindler

make build
 go build -ldflags '-X main.version=8805687-dirty -X github.com/lxc/lxcri.defaultLibexecDir=/usr/local/libexec/lxcri' -o lxcri ./cmd/lxcri
 cc -Werror -Wpedantic -o lxcri-start cmd/lxcri-start/lxcri-start.c $(pkg-config --libs --cflags lxc)
 CGO_ENABLED=0 go build -o lxcri-init ./cmd/lxcri-init
 # this is paranoia - but ensure it is statically compiled
 ! ldd lxcri-init 2>/dev/null
 go build -o lxcri-hook ./cmd/lxcri-hook
 go build -o lxcri-hook-builtin ./cmd/lxcri-hook-builtin

ls -alrt
 total 15288
 [...]
 -rwxr-xr-x 1 debian debian 7108288 Nov 16 20:06 lxcri
 -rwxr-xr-x 1 debian debian 17520 Nov 16 20:06 lxcri-start
 -rwxr-xr-x 1 debian debian 2942584 Nov 16 20:06 lxcri-init
 -rwxr-xr-x 1 debian debian 2834743 Nov 16 20:06 lxcri-hook
 -rwxr-xr-x 1 debian debian 2519097 Nov 16 20:06 lxcri-hook-builtin

Si on était sur une machine de dev, on pourrait envoyer les binaires sur le serveur Proxmox VE (lxcri dans /usr/local/bin, le reste dans /usr/local/libexec/lxcri).

Dans mon cas, je suis directement sur la machine qui build et qui run, je fais donc :

$ sudo make install
 mkdir -p /usr/local/bin
 cp -v lxcri /usr/local/bin
 'lxcri' -> '/usr/local/bin/lxcri'
 mkdir -p /usr/local/libexec/lxcri
 cp -v lxcri-start lxcri-init lxcri-hook lxcri-hook-builtin /usr/local/libexec/lxcri
 'lxcri-start' -> '/usr/local/libexec/lxcri/lxcri-start'
 'lxcri-init' -> '/usr/local/libexec/lxcri/lxcri-init'
 'lxcri-hook' -> '/usr/local/libexec/lxcri/lxcri-hook'
 'lxcri-hook-builtin' -> '/usr/local/libexec/lxcri/lxcri-hook-builtin'

et on peut continuer :

$ /usr/local/bin/lxcri help
NAME:
 lxcri - lxcri is a OCI compliant runtime wrapper for lxc

USAGE:
 lxcri [global options] command [command options] [arguments...]

VERSION:
 8805687
[...]

On reprend crio

Ok, on a buildé lxcri et on a toutes les dépendances pour l’utiliser. On peut donc repartir sur la doc officielle de lxcri “setup.md” dans l’idée de configurer CRI-O, pour qu’il n’utilise pas runc, uniquement lxcri.

sudo tee /etc/crio/crio.conf.d/10-crio.conf > /dev/null <<'EOF'
[crio.image]
signature_policy = "/etc/crio/policy.json"

[crio.runtime]
default_runtime = "lxcri"

[crio.runtime.runtimes.lxcri]
runtime_path = "/usr/local/bin/lxcri"
runtime_type = "oci"
runtime_root = "/var/lib/lxc" #proxmox lxc folder
inherit_default_runtime = false
runtime_config_path = ""
container_min_memory = ""
monitor_path = "/usr/libexec/crio/conmon"
monitor_cgroup = "system.slice"
monitor_exec_cgroup = ""
privileged_without_host_devices = false
EOF

A noter, la doc d’installation setup.md nous dit générer une conf propre avec le binaire crio et la commande config, mais ça ne marche pas vraiment et on se retrouve à lancer runc ou crun sans le vouloir. J’écrase tout, c’est plus simple.

Et maintenant, on peut lancer crio :

sudo systemctl enable crio && sudo systemctl start crio

A partir de là, on a un serveur disposant d’un CRI a priori fonctionnel.

systemctl status crio
● crio.service - Container Runtime Interface for OCI (CRI-O)
 Loaded: loaded (/lib/systemd/system/crio.service; enabled; vendor preset: enabled)
 Active: active (running) since Mon 2025-11-17 12:02:37 UTC; 12s ago

journalctl -u crio
Nov 17 20:29:43 instance-2025-11-16-15-31-55 systemd[1]: Starting Container Runtime Interface for OCI (CRI-O)...
[...]
Nov 17 20:29:43 instance-2025-11-16-15-31-55 crio[11906]: time="2025-11-17T20:29:43.61758425Z" level=info msg="Using runtime handler lxcri version 8805687"

Yeeees :D

On peut donc installer kubelet, puis l’ajouter à un cluster Kubernetes existant

Fast forward

J’avais la flemme de monter un cluster propre avec kubeadm ou autre, et d’enrôler ensuite un node à la main avec le token+sha. J’aurais aussi pu rejouer avec mon PoC rigolo des workers “linux” de Clever Cloud pour créer un control plane chez Clever, puis enrôler à la main avec le node bootstrap token (j’ai fait les choses plutôt bien dans ce PoC).

J’ai donc rejoué à l’arrache avec mon projet demystifions-kubernetes, qui permet de monter un cluster mono node à la main en lançant juste des binaires.

Une fois le control plane bootstrapé (etcd, api-server, controller-manager, scheduler), on s’arrête AVANT la partie containerd (on a déjà configuré CRI-O) et on lance le kubelet à la main :

sudo bin/kubelet --kubeconfig admin.conf --container-runtime-endpoint --container-runtime-endpoint=unix:///var/run/crio/crio.sock --fail-swap-on=false --cgroup-driver="systemd"
[...]
I1117 13:41:58.741561 88434 kubelet_node_status.go:78] "Successfully registered node" node="instance-2025-11-16-15-31-55"

On progresse ! Essayons de voir l’état de santé du cluster et de déployer un pod :

$ export KUBECONFIG=admin.conf
$ kubectl get nodes
 NAME STATUS ROLES AGE VERSION
 instance-2025-11-16-15-31-55 Ready <none> 13m v1.34.2

$ kubectl create deployment web --image=zwindler/vhelloworld
 deployment.apps/web created


$ kubectl get pods
 NAME READY STATUS RESTARTS AGE
 web-6c8cc48c68-cdbtj 1/1 Running 0 4m17s

$ kubectl logs web-6c8cc48c68-cdbtj
 [Vweb] Running app on http://localhost:8081/
 [Vweb] We have 3 workers

Great success!

Conclusion

A partir de là, CRI-O partage le moteur LXC de Proxmox VE de manière fonctionnelle.

Pour s’en convaincre, on peut lancer la commande lxc-ls, qui nous affichera un mix de “vrais” containers LXC (créés avec Proxmox, les 151 et 200) et de containers de pods (les STOPPED sont les init containers de cilium) :

$ lxc-ls -f
NAME STATE AUTOSTART GROUPS IPV4 IPV6 UNPRIVILEGED
151 STOPPED 0 - - - true
200 STOPPED 0 - - - true
3045d1f3abcc069b1009acc869a27b09cf9531d0701a3f9d5a760213d57c7b20 STOPPED 0 - - - false
78057100e5d0613944c2be859dfd09f790eeba88bceebea0e04970841c9bd950 RUNNING 0 - 10.0.0.90 - false
8e5506beea9a50214c46f31fa7fa6d04397963cb912aa397261359865d40a0cd RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
abdcd5be0a27417aa9e11cc2b27882bc86a63d94f547f909332ca7470a5e075a STOPPED 0 - - - false
aeaed9c2f56328bb6196ede4a78f06c4bb2d3edf5dca7912cf38407b9bf6610a STOPPED 0 - - - false
ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d RUNNING 0 - 10.0.0.167, 10.244.0.1, 203.0.113.42, 192.168.1.10 2001:db8::1 false
edb9d42e35a4029cfec5bed5597746bdf67fbe438f21446230252265ed1c849d STOPPED 0 - - - false
$ ps -ef |grep ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d
root 2674943 1 0 22:32 ? 00:00:00 /usr/libexec/crio/conmon -b /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -c ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d --exit-dir /var/run/crio/exits -l /var/log/pods/kube-system_cilium-operator-56d6cd6767-dps78_6082ea2d-331e-4262-b8b3-d3f88eb4e446/cilium-operator/1.log --log-level info -n k8s_cilium-operator_cilium-operator-56d6cd6767-dps78_kube-system_6082ea2d-331e-4262-b8b3-d3f88eb4e446_1 -P /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/conmon-pidfile -p /run/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata/pidfile --persist-dir /var/lib/containers/storage/overlay-containers/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/userdata -r /usr/local/bin/lxcri --runtime-arg --root=/var/lib/lxc --socket-dir-path /var/run/crio --syslog -u ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d -s
root 2674951 2674943 0 22:32 ? 00:00:00 /usr/local/libexec/lxcri/lxcri-start ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d /var/lib/lxc /var/lib/lxc/ed9aaf5a0fd4b11be121296290472d6d71d9016e4c6bb0d05fb2e4a7f4b7a85d/config

Rien ne nous empêcherait ensuite de pousser le vice, et de faire un petit script qui récupère toutes les informations des containers, et crée les fichiers /etc/pve/lxc/xxx.conf associés de manière à les afficher dans l’UI, comme je l’avais fait dans l’article :

Lancer des containers Docker avec Proxmox VE (et LXC)

En théorie, si cette étape avait du sens, je pourrais créer les releases moi-même sur mon fork pour faciliter l’installation.

Enfin, je pourrais essayer de contribuer mes modifications pour que tout soit mergé sur le projet principal, à ceci près que les mainteneurs refusent les PRs car le projet n’est plus maintenu.

Mais j’avoue qu’après probablement une quinzaine d’heures de debug, de Golang, de compilation C, réparties sur 2 ans, j’ai un peu été au bout de ma patience pour cette “blague”.

OK, c’était débile, maintenant que j’ai réussi, dodo X_X.

Lancer des containers Docker avec Proxmox VE (et LXC)

Mon, 07 Nov 2022 06:30:00 +0200

Introduction

J’ai trouvé plusieurs tutos pour installer Docker (engine) à l’intérieur d’un container LXC sous Proxmox VE pour ensuite lancer des containers Docker dedans. Le souci c’est que vous devez vous logger dans le container LXC avant de pouvoir interagir avec vos containers Docker.

On peut aussi installer Docker directement sur Proxmox VE mais ce n’est pas trop conseillé et on n’a pas la facilité d’usage de LXC avec la GUI de Proxmox.

Et en fait, il se trouve qu’on peut lancer des images Docker comme l’OS d’un container LXC et ainsi avoir des Docker pilotés par Proxmox. On aura donc pas un comportement 100% identique à si vous aviez fait un docker run sur votre machine.

Cependant, on gagnera un échange un container totalement identique à vos autres containers LXC de votre cluster (avec toutes les fonctions associées) mais lancé avec une image Docker.

Mais d’abord je vous propose de revenir un peu en arrière avant de vous montrer comment…

Contexte

Vous le savez, je fais du Proxmox VE depuis un moment. Proxmox VE est une super distribution clé en main et production ready de virtualisation de serveurs (c’est même de l’hyperconvergé si on active la partie Ceph).

Il y a plein de petites choses que j’aime avec Proxmox VE, et l’une d’elle est qu’on peut créer des containers Linux avec LXC plutôt que des machines virtuelles QEMU. J’avais fait un article pour en parler.

A l’usage (sauf paramétrage kernel spécifique) le container LXC se comporte de manière strictement identique à une VM dans Proxmox, mais pour une fraction des ressources ! On a un OS, on installe des applications dessus, comme une VM.

Un frontal nginx pour plusieurs applications. Le container LXC complet ne consomme que quelques Mo

Certes c’est beaucoup moins bien isolé qu’une vraie VM (car c’est un container, on est isolé des autres processus, mais on tourne sur le kernel de l’hyperviseur directement).

Mais avec si peu de besoins en ressources, je peux héberger de nombreuses petites applications dans des contextes différents avec de très petites machines physiques (des Atom 4Go de RAM à 6€ par mois chez OneProviders) ce qui serait impossible avec une vraie VM.

C’est bien, mais pas suffisant

Cependant, LXC n’est pas la techno de containerisation la plus connue/hype. Depuis des années sur le forum, à chaque fois que des gens demande le support de Docker dans Proxmox VE, on les envoie balader. Pas toujours très gentiment d’ailleurs…

Pourtant, il y a plusieurs raisons pour avoir envie de lancer des containers Docker sur son infra Proxmox :

D’abord, Docker n’est pas autant des workloads stateless et/ou éphémères qu’on le croit. Beaucoup d’applications containerisées auraient toute leur place sur un cluster de virtualisation.
Ensuite parce que beaucoup d’éditeurs de logiciels sont devenus faignants. Certains ne gèrent plus les processus d’installation (ou alors juste sur un OS) et fournissent juste une image Docker qu’ils maintiennent mise à jour.

On doit donc se contenter de VMs dans Proxmox pour lancer des containers Docker (cf mon point du début).

LXC supporte les images OCI

Coup de théâtre. Il y a quelques jours, j’ai découvert que LXC, le moteur de containerisation de Proxmox VE, était compatible avec le format OCI.

buzzwrd.me - Creating LXC containers from docker and OCI images

Pour ceux qui ne connaissent pas OCI, il s’agit d’une organisation visant à créer un standard pour unifie la façon de stocker les containers.

The Open Container Initiative is an open governance structure for the express purpose of creating open industry standards around container formats and runtimes. opencontainers.org/

Et Docker respecte ce format : on peut donc théoriquement lancer depuis LXC des containers dont l’image de base est une image Docker.

Je suis profondément choqué (Réf “Jean François Coppé” pour ceux qui n’ont pas le mème)

Bon, quand est-ce qu’on commence ?

Disclaimer: ce qui suit est de la bidouille. Rien n’est supporté et je ne le conseille pas en production. Il est probable qu’il y ait aussi des limitations (notamment pour ce qui est stockage).

D’abord, il manque quelques dépendances pour que la fonction OCI de LXC soit utilisable sous Proxmox VE :

sudo apt install skopeo umoci jq

Ensuite, par défaut, les containers LXC s’attachent à un bridge linux qui s’appelle lxcbr0. Cependant ce bridge n’existe probablement pas sur votre installation de Proxmox VE (pas installé par défaut).

En quick and dirty, on peut juste remplacer le nom par défaut, même si idéalement il faudrait trouver le flag dans la CLI pour changer le bridge. En fonction de comment vous avez configuré le réseau dans votre serveur Proxmox VE, vous allez probablement utiliser vmbr0 ou vmbr1 :

sed -i 's/lxcbr0/vmbr1/g' /etc/lxc/default.conf

Maintenant qu’on a tout, on peut lancer nos containers LXC à partir d’images docker. Ici je lance l’image officielle alpine:latest, mais j’aurais pu prendre n’importe quelle autre :

lxc-create 500 -t oci -- --url docker://alpine:latest

J’ai créé un container appelé “500” (car les VMs et les containers LXC dans proxmox VE sont appelés avec des nombres). L’image est téléchargée puis le container créé :

On peut maintenant le démarrer (avec lxc-execute on lance le container et ouvrir un prompt directement dedans, mais on a aussi lxc-start et lxc-attach)

lxc-execute 500

Tel quel, Proxmox VE ne sait pas que notre container existe et il n’apparaitra pas dans l’UI. Mais ça fonctionne ;-).

Bonus

On peut même tricher et faire croire à Proxmox que c’est un container LXC qu’il a créé lui-même en créant un fichier 500.conf, dans le dossier /etc/pve/lxc/

Les seules lignes obligatoires sont les suivantes :

arch (amd64 sauf si vous êtes sur ARM)
cores (la limite de CPUs à imposer au container)
hostname
memory (la limite de RAM à imposer au container)
ostype
rootfs

Une fois le fichier créé, automatiquement le container apparait dans la liste des VMs de l’hôte. On peut le démarrer et ça fonctionne :)

Le container pourra être démarré, arrêté, etc. Le tout depuis la GUI de Proxmox VE :)

Have fun!

Source

Migrer une VM de Proxmox VE vers XCP NG

Sun, 24 Jul 2022 12:00:00 +0000

Retour de la virtualisation

Ca fait quelques mois que je n’ai pas parlé de virtualisation donc forcément, ça me démange un peu ;).

Si vous suivez ce blog depuis quelque temps, vous savez pourtant que j’ai pas mal roulé ma bosse avec Proxmox VE, un OS clé en main de virtualisation KVM (mais aussi de containerisation LXC, on en parle tellement peu). Sans aller jusqu’à dire que j’en ai fait le tour (a-t-on jamais fait le tour d’une techno ?), je commence à manquer de choses à tester avec mon lab perso.

L’an dernier, j’ai discuté avec les équipes de Vates SAS à OSXP 2021, une boite qui publie une autre distribution open source dédiée à la virtualisation : XCP-NG (mais basée sur XenServer).

J’en avais déjà entendu parler sur Twitter (coucou Cécile) donc j’étais un peu curieux. Mais j’étais aussi un peu sceptique, ma dernière expérience de XenServer datant de 2011.

Dans cet article, je ne vais pas rentrer dans une comparaison des fonctionnalités ni des avantages et inconvénients de XCP-NG par rapport à Proxmox VE. Je n’ai pas encore assez testé pour me faire une idée pertinente (ça viendra).

En revanche, je peux vous donner un premier avant goût de la solution via un petit tuto pour vous aider à migrer des VMs de l’un à l’autre, si jamais l’envie vous prend de tester.

Prérequis

Dans ce tutoriel, je pars du principe que vous avez :

d’un côté, une machine virtuelle QEMU, hébergée par un Proxmox VE, à copier/migrer
de l’autre, un serveur sous XCP-NG, dans le même LAN, gérée par XenOrchestra (l’équivalent du vCenter de VMware, pour ceux à qui ça parle)

Note: sauf erreur de ma part, on a pas de solution clé en main pour migrer un container LXC vers XCP-NG (même si XenServer gère les containers Xen, aussi appelé virtualisation PV). Trouver comment migrer ces workloads LXC sera peut-être l’objet d’un prochain article.

Pour le reste du tutoriel, on va grosso modo suivre la documentation officielle disponible ici, mais avec quelques modifs et surtout un peu plus de détails.

Option ZFS

Note: J’installe mes serveurs Proxmox VE avec ZFS comme stockage. Ca a plein d’avantages, notamment celui de me donner la possibilité de faire, à peu de frais, un PRA avec une réplication asynchrone des machines virtuelles de mon cluster. Cela induit par contre une petite difficulté complémentaire (vous allez voir c’est léger). Vous pouvez sauter cette étape si vous n’utilisez pas ZFS.

Pour rappel (je ferai aussi un article dédié à ça), avec ZFS j’ai 2 types de disques.

# zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 213G 15.9G 112K /rpool
rpool/ROOT 6.32G 15.9G 96K /rpool/ROOT
rpool/ROOT/pve-1 6.32G 15.9G 6.32G /
rpool/data 2.84G 15.9G 2.84G /rpool/data
rpool/subvol-201-disk-0 3.43G 4.57G 3.43G /rpool/subvol-201-disk-0
rpool/subvol-301-disk-0 604M 15.9G 604M /rpool/subvol-301-disk-0
rpool/vm-100-disk-0 3.79G 15.9G 3.79G -
rpool/vm-213-disk-0 184G 148G 38.2G -

Des disques de type “Filesystem” qui sont directement montés à la racine de mon espace de stockage ZFS (chez moi /rpool, mais on a aussi /tank comme convention chez les aficionados de ZFS) pour les containers LXC.

# zfs get type rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 type filesystem -
# zfs get mountpoint rpool/subvol-301-disk-0
NAME PROPERTY VALUE SOURCE
rpool/subvol-301-disk-0 mountpoint /rpool/subvol-301-disk-0 default

Pour les VMs KVM/QEMU en revanche, je ne peux pas directement trouver un fichier toto.raw ou toto.qcow2 dans l’arborescence /rpool. Côté ZFS, ces volumes sont des volumes de type “volume” (lol).

Mais c’est un détail, car c’est presque encore plus facile puisqu’on peut aller directement dans /dev/zvol/rpool et les retrouver en tant que “special file” dans /dev.

ls -l /dev/zvol/rpool/vm-100*
lrwxrwxrwx 1 root root 10 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0 -> ../../zd16
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part1 -> ../../zd16p1
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part2 -> ../../zd16p2
lrwxrwxrwx 1 root root 12 Jul 23 02:00 /dev/zvol/rpool/vm-100-disk-0-part5 -> ../../zd16p5

Dans l’étape suivante, /dev/zvol/rpool/vm-100-disk-0 remplacera donc notre image disque “input” (toto.img).

Générer un VHD

Souvent sous Proxmox, vous allez avoir des disques au format RAW ou au format QCOW2.

Dans les deux cas, XCP-NG n’accepte pas ces formats. Heureusement, l’utilitaire qemu-img, inclus dans notre distribution de Proxmox VE sait faire les conversions.

Dans le cas d’un disque RAW :

qemu-img convert -f raw toto.img -O vpc toto.vhd

Dans le cas d’un disque QCOW2 :

qemu-img convert -f qcow2 toto.qcow2 -O vpc toto.vhd

Avant d’importer le VHD dans XCP-NG

La partie un peu moins “fun” de la procédure est qu’on doit faire une partie des actions en GUI (si on suit la doc, mais je teaserai qu’on peut faire mieux en fin d’article).

La première chose qu’on va devoir faire, c’est aller dans la WebUI Xen Orchestra pour retrouver notre espace de stockage et créer manuellement un disque.

Il faut aller retrouver la liste de nos espaces de stockages (le plus simple, c’est de passer par “home”), puis, dans cet espace, créer un nouveau disque. Prenez garde à le créer de la bonne taille, en faisant attention à la différence Go/Gio. La documentation officielle conseille d’ajouter 1 Go de marge pour éviter ce genre de problématiques, mais je n’en ai pas eu besoin lors de mes tests.

Note: chaque disque et chaque “datastore” a son propre UUID. Ici, j’ai souligné en rouge celui du datastore “Local”, il nous servira plus tard (quand on passe la souris dessus, XOA nous propose de le copier dans le presse-papier).

Une fois le disque créé à la bonne taille, on récupère son UUID aussi.

VHD vers XCP-NG

Maintenant qu’on a d’un côté un VHD valide, et de l’autre un disque dur virtuel vide prêt à accueillir les données, on peut se lancer !

On envoie le VHD sur le serveur XCP-NG (via scp ou un montage NFS, par exemple) et on se connecte dessus en SSH.

Si on est pas confiant, on peut tester que le VHD est valide sur XCP-NG grâce à l’utilitaire suivant :

# vhd-util check -n /nfs/toto.vhd
 /nfs/toto.vhd is valid

Ensuite, on utilise le binaire xe qui permet d’interagir en CLI avec XCP-NG pour lancer l’import :

# xe vdi-import filename=/nfs/toto.vhd format=vhd --progress uuid=aaaaaaaa-aaaa-aaaa-aaaa-aaaaaaaaaaaa
 [|] ######################################################> (100% ETA 00:00:00)

On aura évidemment remplacé le paramètre uuid=aaaa par l’UUID du disque virtuel, que je vous ai demandé de récupérer plus tôt !

Créer la VM

Normalement, à l’issue de l’opération, on a un disque tout beau tout propre. La dernière étape est de créer une VM et à lui attacher ce disque.

Là encore, on peut repartir de “Home” puis aller dans le menu VM.

Note: pour passer le menu de création de VM, il faut impérativement choisir soit ISO/DVD ou PXE dans Install settings, sinon CREATE est grisé. J’ai également supprimé le disque par défaut proposé par le wizard (puisqu’on va lui en attacher un) et dans Advanced, j’ai décoché Boot VM after creation puisque de toute façon je dois lui attacher le disque avant de booter.

Une fois créé, on clique sur la VM pour lui attacher le disque qu’on a importé.

On peut maintenant booter la VM !

Lors du redémarrage, la seule chose que j’ai eu à changer était la configuration réseau, un peu différente entre mon cluster Proxmox VE et mon lab XCP-NG, ainsi que le nom d’interface qui était différent suite au passage à Xen (ens18 => eth0).

J’ai également ajouté le “Management agent” pour bénéficier d’infos dans l’UI (et probablement d’autres trucs chouettes que je n’ai pas encore exploré).

Conclusion

Voilà pour ces premiers pas avec XCP-NG. Comme vous avez pu le constater, l’opération nécessite plusieurs étapes, dont certaines peuvent être améliorées (notamment l’automatisation de certaines tâches côté XCP-NG grâce à l’API, on en reparlera, car j’ai déjà quelques résultats).

Cependant, ça permet déjà de se faire une première impression et de se familiariser avec les menus.

Dans les semaines qui viennent, je vais continuer de jouer avec, histoire de me faire une opinion un peu plus construite de XCP-NG (notamment par rapport à ce que je fais avec Proxmox). S’il y a des points que vous voulez que je creuse en particulier, n’hésitez pas à me “ping” sur les divers réseaux sociaux pour m’en parler.

D’ici là, have fun :)

QNAP débranche LXC sur les NAS ARM : comment contourner ?

Mon, 13 Jun 2022 08:00:00 +0200

Si vous le suivez sur Twitter ou Masto, vous m’avez très probablement lu râler contre la sortie ~~de QTS 5~~ Container Station v2.4.0.2316, l’été dernier.

Ou plus particulièrement, contre une décision prise lors de ce passage : enlever LXC pour l’administration des containers, au profit de LXD. LXD étant juste une couche d’administration, LXC est toujours présent et fonctionnel, juste caché.

Pourquoi je râle ?

J’ai un NAS QNAP TS431P2 depuis 2018 dont je suis pleinement satisfait, et qui m’a permis de passer moins de temps à administrer et ajouter des fonctionnalités à mon NAS ZFS maison, monté initialement en 2011 (merci Dworak_of_sky pour les souvenirs).

Sauf que mon QNAP est un NAS milieu de gamme, fonctionnant avec un processeur ARM et pas x86 ! Et ces charmantes personnes (grrrr) de chez QNAP n’ont pas porté LXD sur les NAS ARM (segmentation artificielle de l’offre ? Flemme ?).

Nous, propriétaires de NAS QNAP ARM, nous retrouvons donc sans solution puisque LXC est désactivé et LXD pas disponible.

Une fonction hyper pratique pour héberger de petits services à bas coût (autant en performance qu’en prix) disparaît. C’était un réel différenciant pour ce modèle et je me sens vraiment trahi (ou alors c’est ma faute, car je n’aurais pas dû leur faire confiance ?).

Je ne suis pas près de recommander QNAP comme j’ai pu le faire par le passé. #PasContent

Nuance

HEUREUSEMENT, les containers LXC ne se sont pas mis à ne plus marcher du jour au lendemain.

Enfin, encore heureux ! Je n’ose imaginer les dégâts en prod !

C’est d’autant plus vicelard que le message d’information pour expliquer qu’il n’y a plus LXC indique que c’est pas grave puisque vous avez LXD à la place. Aucune mention du fait qu’en fait, sous ARM, non…

Il est toujours possible (pour l’instant) de démarrer, arrêter, utiliser et supprimer les containers existants. Mais il n’est plus possible d’en créer de nouveaux.

Ça veut donc dire que tout est encore présent pour faire fonctionner la fonctionnalité, ce n’est “juste” plus disponible en UI.

En avoir le coeur net

En farfouillant, je me suis aussi rendu compte qu’il était toujours possible d’exporter des containers existants et d’importer les exports.

On peut donc contourner la limitation arbitraire de QNAP via des export / import. J’ai l’habitude de ce genre de bidouilles, puisque je faisais déjà ça il y a plus de 10 ans avec les hyperviseurs VMware en licence gratuite…

A l’usage, ça fonctionne mais c’est pas satisfaisant. D’abord parce que si on a pas, ou plus, de containers sur le NAS, on ne peut pas le faire trivialement.

Ensuite, parce que le processus et long (l’export et l’import) et pénible (plusieurs étapes).

Enfin, parce que les images LXC mises à disposition par QNAP étaient antédiluviennes !

Ubuntu 14.04 !!! Sauf si vous avez pris le temps de faire le processus d’upgrade complet de 14.04 à 20.04 ou 22.04 (et vous devriez), il est probable que vous n’ayez pas envie de repartir de ces vieux machins.

“Faites mieux”

Si vous êtes admin, vous avez probablement déjà activé SSH pour vous connecter directement à l’OS de votre NAS. (Et sinon vous pouvez aller ici pour l’activer)

Une fois connecté, on peut sortir du menu TUI et bidouiller l’OS comme on en a envie.

[~] # id
uid=0(admin) gid=0(administrators)

Je n’ai pas fait beaucoup d’administration LXC/LXD directement, car j’avais toujours une interface à ma disposition pour me “cacher” la façon dont ça fonctionne vraiment, que ce soit dans le cas de QNAP ou de Proxmox VE (que j’utilise beaucoup pour ça).

En lisant rapidement la doc sur ubuntu-fr, j’ai compris qu’il existait en fait chez Canonical un genre de dépôt d’images officielles de pleins d’OS, notamment compatible armhf.

Avec LXC, on peut accéder directement à ces images en ligne de commande avec lxc-download. Pas de bol, la commande n’est pas dispo sur QTS :

[~] # lxc-download
-sh: lxc-download: command not found

(En fait elle n’est juste pas dans le PATH, mais je ne le savais pas à ce moment-là)

Sauf qu’on peut aussi appeler directement la commande pour créer des containers lxc-create avec un flag “download”. Et ça tombe bien parce que lxc-create est disponible. Mais la joie sera de courte durée…

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf

/usr/local/container-station/lxc/share/lxc/templates/lxc-download: line 237: getopt: command not found

Hack…

Note : si vous trouviez que ce qu’on était en train de faire n’était déjà pas très propre, je tiens à vous prévenir, la suite est vraiment immonde… Pas merci QNAP de me forcer à faire ça !

Le script /usr/local/container-station/lxc/share/lxc/templates/lxc-download est moisi. Il manque la moitié des binaires dans la busybox.

Pire encore, la procédure que je donne ici semble être écrasée à chaque mise à jour de l’application Container Station. Mais, ça fonctionne…

La première chose qu’on va faire, c’est faire une sauvegarde du script lxc-download par sécurité.

cp /usr/local/container-station/lxc/share/lxc/templates/lxc-download{,.old}

Le premier message d’erreur qu’on a getopt: command not found indique juste que de nombreux binaires “classiques” ne sont pas disponibles directement dans le shell de QTS.

Sauf qu’en fait, ils sont là, ces binaires. Pas besoin de les télécharger ou de les compiler. Ils ne sont juste “pas visibles”.

QTS tourne, comme beaucoup de serveurs Linux minimalistes, avec l’aide de Busybox.

On peut donc “magiquement activer” les binaires qui nous manquent simplement avec des liens symboliques.

for binary in getopt xz seq; do
 ln -s /share/CACHEDEV1_DATA/.qpkg/container-station/bin/busybox /share/CACHEDEV1_DATA/.qpkg/container-station/bin/${binary}
done

getopt
getopt: missing optstring argument

… and slash!

C’est bon, mais pas suffisant.

La version du binaire mktemp de busybox n’est malheureusement PAS compatible avec le script lxc-download. On va devoir le modifier à la main…

Usage: mktemp [-dq] TEMPLATE

Le passage problématique se situe autour des lignes 320-325

320 if ! command -V mktemp >/dev/null 2>&1; then
321 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmp/lxc-download.$$"
322 else
323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}$(mktemp -d)"
324 fi

En vrai, mktemp s’attend à avoir le path complet, accompagné d’un pattern à base de XXXXXX. mktemp remplace ensuite les caractères XXXXXX par un nombre aléatoire en s’assurant que le dossier n’existe pas déjà, puis le créé. Par exemple

mktemp /tmp/mydirXXXXX

Mode bourrin, j’ai remplacé la ligne par :

323 DOWNLOAD_TEMP="${DOWNLOAD_TEMP}/tmpdir" && mkdir -p ${DOWNLOAD_TEMP}

De toute façon, il est supprimé à la fin de l’exécution du script, ce dossier (fonction cleanup dans le shell).

GPG

On progresse !

[~] # lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf
Setting up the GPG keyring
chmod: /var/lib/lxc/container_jammy/tmpdir/gpg: No such file or directory
Error creating container container_jammy

En creusant un peu, la vraie erreur est que je n’ai pas le binaire gpgkeys_curl à l’endroit attendu :

gpg: unable to execute program `/opt/cross-project/arm/linaro/arm-linux-gnueabihf/libc/libexec/gnupg/gpgkeys_curl': No such file or directory

Voilà un autre point que je n’ai pas réussi à corriger correctement.

Le plus simple est de simplement ignorer la validation avec --no-validate mais si vous avez une piste, je suis preneur.

lxc-create -t download -n container_jammy -- -d ubuntu -r jammy -a armhf --no-validate

Des dossiers qui disparaissent tout seul ???

Dernier mystère…

Downloading the image index
ERROR: Failed to download http://images.linuxcontainers.org//meta/1.0/index-system

L’erreur n’est pas du tout un problème d’accès à l’URL pour télécharger l’index des systèmes disponibles sur images.linuxcontainers.org (code 302, page redirigée sur uk.lxd.images.canonical.com).

En réalité, si active les messages d’erreurs lors du wget dans le script, l’erreur est que le dossier /var/lib/lxc/container_jammy/tmpdir/ n’existe pas !

Pourtant, ça devrait être corrigé, suite à la modif qu’on a faite ligne 323 (voir plus haut)… trop bizarre :/

J’en ai eu un peu marre de creuser et au bout d’un moment, j’ai juste fait :

export CONTAINER_NAME=jammy
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/tmpdir/
mkdir -p /var/lib/lxc/${CONTAINER_NAME}/rootfs/
lxc-create -t download -n ${CONTAINER_NAME} -- -d ubuntu -r jammy -a armhf --no-validate

Et croyez-le ou non, mais ça marche ! Le container existe (il n’est juste pas visible dans la console pour l’instant)

[...]
You just created an Ubuntu jammy armhf (20220611_07:42) container.

On a plus qu’à redémarrer Container Station, il apparaît

Conclusion

Si jamais quelqu’un de chez QNAP lit ce blogpost… Arrêtez de vous fiche de nous et :

mettez nous LXD dans nos NAS ARM
OU si c’est trop de boulot (je peux l’entendre), remettre LXC en attendant.

Ce genre de hack est indigne et j’ai perdu plusieurs heures pour corriger votre m***e. J’ai payé pour un NAS compatible LXC, ce n’est pas pour que vous retiriez la fonctionnalité 1 an après.

Ce genre de pratiques est vraiment dégueulasse et je n’hésiterais pas à dire tout le mal que je pense de cette décision.

Sources

Ajouter une clé USB à un container LXC

Mon, 25 Oct 2021 06:25:00 +0000

Il arrive souvent, quand on fait de la virtualisation, qu’on ait besoin de « passer » un device physique, notamment des clés USB, à une VM et essayer de lui faire croire qu’on lui a branché physiquement (alors que c’est l’hôte qui l’a).

Quand il s’agit de virtualisation complète, c’est, paradoxalement, relativement simple. Comme l’OS invité est totalement isolé de l’OS hôte, il est nécessaire d’ajouter un programme pour faire passer dans un tunnel les commandes envoyées/reçus par le device et d’ajouter une couche d’émulation dans la VM pour lui faire croire qu’elle a le device connecté.

Il est souvent très facile de faire ce genre d’opération dans les hyperviseurs du marché depuis très longtemps. J’avais par exemple fait une série d’articles en 2016 (!!!) sur la façon de le faire dans VMware.

Cependant, dans le cas de container LXC sur mon Proxmox (mais la logique sera la même pour LXD ou même un LXC nu), c’est bizarrement plus compliqué. Je vais vous montrer comment faire dans cet article.

Récupérer les informations

Sur l’hôte, utiliser l’utilitaire lsusb pour lister les devices connectés. Récupérer les nombres Bus et Device (ici 001 et 003) pour en déduire le chemin vers le fichier spécial du device.

root@host01:~# lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Récupérer le major number et le minor number du fichier spécial /dev/bus/usb/{{Bus}}/{{Device}} (ici 189 pour le major et 2 pour le minor)

ls -al /dev/bus/usb/001/003
crw-rw-r-- 1 root root 189, 2 Jul 24 09:46 /dev/bus/usb/001/003

Configurer le container LXC

Maintenant qu’on a les 4 nombres, éditer le fichier de configuration du container 101. Le major+minor sert pour autoriser le container à manipuler le device et le chemin vers le fichier spécial doit être monté exactement au même endroit dans le container LXC

vi /etc/pve/nodes/host01/lxc/101.conf
lxc.cgroup.devices.allow: c 189:2 rwm
lxc.mount.entry: /dev/bus/usb/001/003 dev/bus/usb/001/003 none bind,optional,create=file

Rebooter le container. Normalement le device USB est bien présent.

Pour vérifier, on peut installer usbutils dans le container pour vérifier que la clé est bien disponible avec lsusb.

apt install usbutils
lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Jeedom dans un container LXC

Mon, 04 Oct 2021 06:15:00 +0000

Jeedom + bluetooth pour de la domotique accessible

Note : je vous spoil tout de suite la fin : il n’est pas possible de faire fonctionner une clé USB bluetooth dans un container LXC. Du coup ma plateforme Jeedom ne peut pas fonctionner avec mon dongle bluetooth et j’ai du tout réinstaller dans une VM. Le tutoriel reste globalement applicable, si vous n’avez pas de dongle bluetooth ou si vous installez une VM.

Il y a quelques mois, j’ai décidé de tenter de domotiser un peu ma maison. Comme j’aime bien grapher tout ce qui me passe sous la main, j’ai commencé par acheter un pack de 4 capteurs de température + hygrométrie Xiaomi dans les chambres et le salon.

L’avantage principal de ces petits thermomètres connectés est qu’ils sont très peu chers, majoritairement parce qu’il s’agit de thermomètres bluetooth, beaucoup plus répandu (et donc moins coûteux) que les équivalents zigbee, z-wave, etc.

On peut donc aussi très facilement les appairer à un smartphone (Xiaomi fourni une application pour faciliter la tâche un peu plus) et aussi les intégrer à une plateforme domotique (Xiaomi propose une passerelle Bluetooth) quelconque. Mais l’application smartphone est très limitée et nécessite d’être à très courte portée (of course).

Depuis des années, je sais également que beaucoup de hobbyists de la domotique utilisent Jeedom comme solution de domotique gratuite… D’autant que les solutions d’installations proposées par Jeedom sont nombreuses ! Installation baremetal, sur raspberry pi (ARM), dans une VM, dans un container Docker, etc…

Mais je n’avais rien pour l’installer…

Choix de l’installation

Heureusement, après quelques années en full hébergé, j’ai finalement repris un serveur auto-hébergé dans mon DC-buanderie ™. L’occasion de pouvoir disposer d’un peu plus de puissance en local (aka chez moi) et aussi de relancer mes velléités de domotique auto-hébergée !

J’aurai pu installer Jeedom sur une VM de mon Proxmox, comme tout le monde. Mais comme je suis un original, j’ai préféré l’installer à la mimine sur un container LXC de mon hyperviseur.

(La vraie raison c’est que j’aime bien éviter l’overhead CPU et RAM des VMs en faisant plutôt des containers LXC…)

Récupérer l’OS

Le guide d’installation Jeedom pour une VM n’est ni plus ni moins que l’installation d’une VM Debian 9 (mais 10 ou 11 ça serait pareil). On peut donc le reprendre tel quel, mais avec Proxmox et LXC.

Télécharger une image de container Debian 10 sur un des datastore du Proxmox

pveam update && pveam available --section system | grep debian
system debian-10-standard_10.7-1_amd64.tar.gz
system debian-11-standard_11.0-1_amd64.tar.gz
system debian-9.0-standard_9.7-1_amd64.tar.gz
pveam download rpool-data debian-10-standard_10.7-1_amd64.tar.gz
downloading http://download.proxmox.com/images/system/debian-10-standard_10.7-1_amd64.tar.gz to /rpool/data/template/cache/debian-10-standard_10.7-1_amd64.tar.gz
[...]

Ou si vous voulez frimer parce que vous êtes en Proxmox 7, vous pouvez le DL depuis l’interface graphique

A partir de là, on crée un container LXC (bouton CT) comme d’habitude. Niveau spécification du container, je n’ai pas mis grand-chose et ça a l’air bien suffisant. De toute façon, ça tourne sur des raspberry pi donc c’est peu gourmand.

1 vCPU
1024 Mo de RAM
10 Go de disque

Une fois le CT booté, on se connecte, on le met à jour

sudo apt update
sudo apt dist-upgrade

Puis on récupère le script d’installation de la mort de Jeedom et on l’exécute les yeux fermés 🙈 (ne faites pas ça en prod). J’ai un peu de mal à croire que des gens sérieux osent proposer encore ce genre de méthode d’installation mais bon…

wget https://raw.githubusercontent.com/jeedom/core/master/install/install.sh
chmod +x install.sh
./install.sh

A partir de là, un gros script devrait finir par installer Jeedom et si tout s’est bien passé, celui-ci va lancer un serveur web Apache en écoute sur le port 80

root@jeedom:~# lsof -i ":80"
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
apache2 39845 root 4u IPv6 36590854 0t0 TCP *:http (LISTEN)
apache2 39849 www-data 4u IPv6 36590854 0t0 TCP *:http (LISTEN)

So far, so good

Reverse, mon beau reverse

Moi, le HTTP plain sur le port 80, ça me gave. Pas envie d’ouvrir ça aux 4 vents. J’ai donc un reverse proxy qui me permet de gérer de manière centralisée mes services web (ça a tout un tas d’avantages, notamment celui de n’ouvrir qu’un port, de faire de la rupture protocolaire, de gérer de manière centralisée et unifiée les certificats TLS, …).

Parfois, il faut feinter un peu la conf ou réécrire certaines URL, mais dans le cas de Jeedom, une redirection basique semble fonctionner.

location / {
proxy_pass http://192.168.5.6;
proxy_set_header X-Forwarded-For $remote_addr;
proxy_set_header Host $http_host;
}

J’ajoute ensuite un enregistrement pour jeedom dans mon DNS et hop, j’ai une plateforme de domotique accessible de manière sécurisée depuis partout !

Configuration de Jeedom

On peut donc maintenant passer à la doc « Premiers pas » de chez Jeedom !

Je ne vais pas paraphraser leur guide de démarrage, mais ce qu’il faut savoir c’est qu’il faut absolument s’enregistrer sur le « Market » pour pouvoir activer l’extension Bluetooth BLEA qui nous intéresse dans ce tuto. Et comme le compte est demandé lors de la première connexion, autant créer le compte d’abord.

Une fois que c’est fait, on peut se connecter sur notre Jeedom, avec un agréable login/mdp admin/admin qu’il faudra heureusement obligatoirement changer à la première connexion ;)

WOW ! C’est hyper moche, j’étais pas prêt !

Ajouter une clé USB sur un container LXC

Paradoxalement, permettre à un container LXC d’accéder à un device USB sur un container (donc on est dans le même OS, même kernel) est bien moins facile à faire que de faire de l’USB passthrough pour une VM (2 clics clics dans l’interface).

Pourtant, il y a probablement toute sortes d’interfaces et d’émulations pour faire croire à la VM qu’elle a un port USB physique… La magie de l’automatisation ;-).

Je me suis globalement basé sur ces deux guides pour y arriver, et je ferai un article plus détaillé en français une autre fois :

medium.com/@konpat/usb-passthrough-to-an-lxc-proxmox-15482674f11d
gist.github.com/Yub0/518097e1a9d179dba19a787b462f7dd2 (lien mort)

Long story short, il y a plusieurs paramètres à récupérer et un fichier de conf à modifier et à la fin ça donne ça :

lsusb
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 003: ID 0a12:0001 Cambridge Silicon Radio, Ltd Bluetooth Dongle (HCI mode)
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Ajouter le plugin Bluetooth BLEA

Normalement si vous avez une clé USB bluetooth correctement visible dans l’OS où est installé votre Jeedom, vous avez « juste » à activer le plugin Bluetooth Advertisement disponible sur le Market officiel Jeedom.

Une fois le plugin installé, on peut aller le configurer (menu Plugins / Gestion des plugins). Il faut aussi l’activer (Action « Activer »).

Et du coup, comme je vous l’avez spoilé : et là c’est le drame.

Dans la liste « dropdown » permettant de choisir le device Bluetooth USB, le dongle n’apparaît pas…

Cependant, en lisant les logs j’ai assez rapidement trouvé l’erreur et je suis tombé sur ce post sur le forum de Proxmox.

Doing a « hciconfig » on the GUEST system returns: Can’t open HCI socket.: Address family not supported by protocol

Et effectivement, j’ai la même erreur. A partir de là, j’ai pu retrouver ce post qui indique clairement qu’à cause d’une limitation dans les namespaces linux, le bluetooth ne peut pas fonctionner dans un container LXC…

This was extensively discussed in our german forum (link), here’s the gist of it:Bluetooth devices register themselves as a network interface, so passing through the USB /dev node is useless. Sadly, the BT network adapter is not namespaceable, meaning it can’t be assigned to a container the way regular network interfaces can.

J’en reviens donc à ma note du début d’article : si vous n’avez pas de périphérique bluetooth dans votre domotique, vous êtes maintenant probablement l’heureux propriétaire d’un jeedom fonctionnel dans un container LXC, plus léger qu’une VM.

Dans le cas contraire (comme moi) vous n’avez plus qu’à recommencer le processus, cette fois ci dans une VM, puisque là, le passthrough USB de qemu permet de bypasser la limitation du namespacing linux…

Bref, have fun ;-p

Sources additionnelles

Jeedom Premiers pas - doc.jeedom.com/fr_FR/premiers-pas/index
Jeedomiser - jeedomiser.fr/article/dongle-usb-bluetooth-compatible-avec-jeedom/
Forum Proxmox - Bluetooth in LXC container : forum.proxmox.com/threads/bluetooth-inside-lxc-container.33688/
LXD Github issue - github.com/lxc/lxd/issues/3265 (lien mort)

Les soucis que j’ai rencontrés en upgradant Proxmox VE 7

Mon, 19 Jul 2021 06:55:00 +0000

TL;DR - Lisez encore plus attentivement que d’habitude la release note de Proxmox VE 7

La version 7 de mon hyperviseur préférée vient de sortir ! Comme je n’ai rien d’important qui tourne dessus, je me suis dis que c’était une bonne idée de tester la mise à jour day 1 sans préparation.

Ça n’est évidemment pas une bonne idée ;-p.

Au delà de la valse d’upgrades habituelle ainsi quelques features très sympas (SSO surtout), une modification importante est le passage à Debian 11, Bullseye, qui n’est d’ailleurs pas totalement officiellement sortie (même si on est depuis le 17 en Full freeze…), mais aussi les cgroups v2 et leur configuration, ainsi que OpenZFS.

Lisez donc bien :

pve6to7 OK

Si vous avez déjà fait quelques upgrade de Proxmox VE, vous savez qu’à la dernière mineure de chaque version, un binaire pveXtoY est mis à disposition pour vérifier que la machine (ou éventuellement le cluster) est prêt à être mis à jour.

Dans mon cas, pas de soucis, à part un warning sur le fait que mes VMs actives devraient être migrées (mais comme je n’ai pas de stockage partagé, j’accepte ce downtime).

/boot plein

Cette « erreur » ne m’est pas arrivée mais c’est un grand classique de Proxmox VE. Il n’est pas rare que les /boot soient taillés un peu juste lors de l’installation, et que les kernel (ceux de debian + ceux de proxmox qui a le sien, plus récent) prennent toute la place dans le /boot.

Avant de lancer l’upgrade, vérifiez bien que vous avez de la place pour un kernel dans /boot et nettoyez ce qui dépasse

sudo apt autoremove
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following packages will be REMOVED:
pve-kernel-5.4.101-1-pve pve-kernel-5.4.106-1-pve pve-kernel-5.4.73-1-pve pve-kernel-5.4.78-2-pve
0 upgraded, 0 newly installed, 4 to remove and 0 not upgraded.

Dépôts bullseye pas présents chez votre provider

Une partie de mes machines sont hébergées par Online. Je ne sais pas si c’est toujours le cas, mais au moment où j’ai fais l’upgrade, les miroirs n’existaient pas chez eux.

La commande permettant de mettre à jour les fichiers de configuration d’apt n’est donc pas utilisable en l’état si c’est toujours le cas.

Dans mon cas, j’ai donc du aller modifier les dépôts ciblés pour aller chercher un autre miroir FR

cat /etc/apt/sources.list
# deb http://mirrors.online.net/debian bullseye main
#deb http://mirrors.online.net/debian bullseye main non-free contrib
#deb-src http://mirrors.online.net/debian bullseye main non-free contrib
deb http://ftp2.fr.debian.org/debian/ bullseye main contrib non-free
deb-src http://ftp2.fr.debian.org/debian/ bullseye main contrib non-free
deb http://security.debian.org/debian-security bullseye-security main contrib non-free
deb-src http://security.debian.org/debian-security bullseye-security main contrib non-free

hwaddress pour les bridges

Ça c’est LE « piège à c%% » de cette version de Proxmox. C’était d’ailleurs écrit (mais pas hyper clairement) dans la section Known upgrade issues du guide d’Upgrade.

Mais comme ce n’était pas clair ils ont rajouté un gros pavé qui explique un peu mieux le problème :

Jusqu’à présent, il n’était pas nécessaire de donner une adresse MAC à un bridge et ma config réseau n’en avait pas du coup. En lisant, ce message, j’ai (bêtement) pensé « peu importe si Debian en donner une autre après l’upgrade ».

Grave erreur. Comme pas mal de monde, je me suis coupé la chique après reboot. Comme je suis loin d’être le seul, les équipes de Proxmox ont rajouté a posteriori un paragraphe pour expliquer POURQUOI c’est un souci et pourquoi il faut setter soit même la MAC.

TL;DR, récupérez la MAC de vos interfaces réseau branchées sur un bridge avec ip -c link et ajouter la mac address dans votre bridge avant upgrade.

old systemd (< v232) detected, container won’t run in a pure cgroupv2 environment

Là encore, petite surprise due à une mauvaise lecture de ma part. Proxmox VE 6 utilisait déjà les cgroups v2 pour les containers LXC, mais avec une configuration hybride. J’ai donc pensé qu’il n’y avait pas de changement de ce côté.

Grave erreur. Après upgrade, 2 de mes containers LXC en CentOS ont arrêté de fonctionner. Les machines étaient vue « UP » dans l’interface mais impossible de s’y connecter ni de lancer la console. Pas de message d’erreur particulier.

Heureusement, quand on relance les containers, j’ai réussi à voir dans la console l’erreur suivante :

WARN: old systemd (< v232) detected, container won’t run in a pure cgroupv2 environment! Please see documentation -> container -> cgroup version.TASK WARNINGS: 1

Un retour rapide sur les Known upgrade issues permet de trouver le problème assez vite

Grosso modo, Proxmox VE 7 ne supporte plus les CentOS 7 en mode container LXC (sauf à bidouiller des paramètres pour revenir dans l’ancien mode, ce que je n’ai pas fait). Et là, c’était pas fun du tout…

Replication ZFS HS pendant l’upgrade

Petit point d’attention, j’ai eu mes réplications asynchrones de mes VMs via ZFS qui étaient HS entre les nodes de différentes versions (6 vers 6 ok, 7 vers 7 ok, 6 vers 7 KO).

Je n’ai malheureusement pas copié le message d’erreur mais il s’agit d’un bête changement d’arguments dans la ligne de commande entre OpenZFS dans la version de PVE 6 et OpenZFS 2 (PVE 7).

Là, il n’y a pas grand chose à part ne pas trop trainer pour mettre à jour tous vos nodes (ou faire les synchro à la main, peut être ?).

ovs qui ne s’instancie pas, ovs-vsctl show n’affiche rien

Je n’ai pas dig particulièrement, mais j’ai eu un souci assez pénible avec mes bridges OpenvSwitch, qui étaient correctement déclarés dans le fichier /etc/network/interfaces mais qui n’apparaissaient jamais.

Un restart du service n’y faisait rien, pas plus qu’essayer d’ajouter un nouveau bridge en ligne de commandes.

Finalement, ça a fini par « tomber en marche » en ajoutant un bridge OVS depuis la console (et pas en ligne de commandes comme j’avais testé initialement).

Weird. Peut être un coup de « pas de chance ».

Conclusion

Si vous voulez mettre à jour vos Proxmox VE pour bénéficier des nouvelles fonctionnalités (le SSO OpenIDConnect me fait rêver), faites donc bien bien attention de ne pas avoir de containers LXC trop anciens et de bien setter vos mac address dans le fichier /etc/network/interfaces.

Au delà de ça, ça devrait aller maintenant.