Homelab on Zwindler's Reflection

OCI Artifacts as LXC Machine Base on Proxmox 9.1, Finally?

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

Context

A few days ago, the Proxmox VE dev team announced a new version (9.1) whose major new feature is the addition of OCI artifacts support as a base for creating LXC containers.

A long-awaited feature, since in theory it finally opens the door to launching “Docker”-type containers in Proxmox, something the Proxmox devs had always refused.

That’s also why one of my blog articles gets the most traffic on Google (sniff, soon the end of glory):

This article where I explain how to launch Docker containers (via LXC) in Proxmox VE (normally not 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.

Let’s Test? First the Prerequisites

So, I’m curious, how does it work?

First, you need to pre-download the image you’re interested in to your storage (one that can host “CT Templates”).

Fun thing, there’s a button called “Query tags”, which I imagine retrieves a list of tags. Well, it’s not starting well, it doesn’t work (at least not on docker.io…).

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

EDIT: since then, it works again, on all my nodes. Perhaps a temporary issue.

Note: skopeo is precisely one of the dependencies used in my “proxmox+docker hack” article that allows manipulating (mainly downloading) containers from remote registries.

Creating the LXC Container

Now that the template (the OCI image) is available on our storage, we can create an LXC container as usual. Click on “Create CT”, give a CT ID, a password:

For the template, we choose our OCI artifact:

And validate. Proxmox should create our container:

Even though the terminal tells us that application containers may not work well in the JS console, for all the containers I managed to start (see below), I always had a functional console.

So the bet seems rather successful.

Example with docker.io/python:3.11.14-trixie

When It Wasn’t Working (Yet)

I had 2 issues on a Proxmox VE 9.1 (that had been upgraded and tinkered with a bit, in short, a machine that had seen some use) starting an LXC container on OCI base with Proxmox VE 9.1 because I ran into 2 bugs.

I didn’t reproduce these bugs on a “fresh” install.

First Bug: “from scratch” Image

First, my prime-calculator image wasn’t even created.

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

OK, fair enough. My image is a binary “from scratch”, with nothing but the binary, and maybe I made a mistake somewhere…

Still doesn’t work.

Second Bug: Unable to Start

However, even with known images, the container is properly created:

But impossible to start it:

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

Same error with command line:

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?)

After (laborious) investigation, it turns out it’s an AppArmor problem. I don’t know if I caused it with my tinkering or if it’s a more generalized bug for now (probably option 1, but 2 isn’t impossible either…)

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?)

The temporary (and dirty) workaround is to disable the AppArmor profile for lxc-start, and remove any zombie files/processes.

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: You can also disable it permanently, but that’s obviously something you shouldn’t do.

From there, the container is accessible, sometimes in console (depends on the container)

Conclusion

Apparently, the problems I encountered don’t reproduce on a “fresh install”. So it’s probably an issue related to my “old” machines.

As a bonus, another article in English that made me persevere when I understood it worked for some:

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

Note: this article helped me rediscover the pct enter CTID command that allows you to log into the container.

In the meantime, you still have my hack ;-)

MicroStack evolves: HP EliteDesk and Lenovo ThinkCentre compatibility for your homelab

Wed, 17 Sep 2025 12:00:00 +0200

A MicroStack update? 😍

Yes! A few months ago, I introduced you to MicroStack, my 3D printed modular rack project for Dell Micro. The project had unexpected success on MakerWorld / Bluesky (and even a bit on Reddit) and I received several requests to extend compatibility…

And since I’m nice (and I like my 3D printing side projects), I decided to respond to community requests!

Promise kept: HP EliteDesk and Lenovo ThinkCentre!

In the original article, I mentioned that “a version compatible with Lenovo ThinkCentre Tiny was planned”. Well… it’s done! And I even made a bonus with HP EliteDesk/ProDesk because… why not?

Now, the MicroStack project officially supports three ranges of mini-PCs:

Dell OptiPlex Micro (all generations) - the pioneer
Lenovo ThinkCentre Tiny
HP EliteDesk/ProDesk

A growing ecosystem

The concept remains the same: stackable and modular modules to neatly organize your homelab. But now, you can mix brands in the same rack if you have a heterogeneous fleet (and we all know how it happens in homelabs… “oh look, this used machine is at a good price!”).

The complete MicroStack collection now includes:

PC Modules:

Dell Micro Module - the original
Lenovo ThinkCentre Module - the requested one (thanks to a loan from someone on LinkedIn! Thanks!)
HP EliteDesk/ProDesk Module - the bonus

Common Modules:

Storage Module - for switch, accessories, etc.
Hat - clean rack finish

All these modules are inter-compatible and use the same stacking system.

Still the same best practices

As with the original, I still recommend printing in PETG (or even ASA or ABS?) rather than PLA for better heat resistance, even though these mini-PCs remain quite cool. The honeycomb floor design ensures good ventilation while saving filament.

The feedback: multi-range modeling

Adapting the original design to new ranges was simpler than expected, thanks to the solid foundation of the initial project. Once the concept was established with the Dell module, you “just” need to:

Take (precise!) measurements of the new models (still need to find them…)
Adapt the chassis dimensions
Do one (or more) test prints and validate stacking (the stress, every time, of having burned 120g of plastic for nothing if you messed up)

Each new module took me about an hour of modeling, much less than the initial 3x2h of the original project. Prototyping (testing incomplete versions to save plastic) took quite a bit of time, which I had forgotten to count in the previous article. Easily a few more hours.

Community feedback

What makes me happiest is seeing that the project found its audience. The feedback on MakerWorld is generally enthusiastic and the evolution requests show that the concept really meets a need.

Some users have already sent me photos of their mixed installations with different brands in the same rack. This is exactly the modular spirit I wanted to bring to the project!

I also had one negative feedback, for which I can’t do much as it stands but which was interesting and allowed me to add a warning. The fact that the back is dedicated to the charger (PSU) blocks some ports, particularly for the Lenovo. The solutions:

Live with only Ethernet (for a lab, personally I think that’s fine)
Move the power supplies to the “storage” module

And now?

With these three ranges covered, my MicroStack project becomes really versatile. If you have suggestions for other mini-PCs to support, don’t hesitate! MinisForum, perhaps?

If this project interests you, feel free to comment, share, provide feedback, or even boost the three models for those who have a MakerWorld account (it’s free, but it’s appreciated :-P).

MicroStack - an open source project to 3D print a modular rack for my Dell Micro homelab

Sat, 22 Mar 2025 12:00:00 +0200

AGAIN? Another evolution of your lab???

If you’ve been following the lore of my blog a bit, you know I have as many versions of my homelab as years of experience XD.

2025 will be no exception. In early 2024, I embarked on the construction of a rack based on aluminum profiles and 3D printing (in french), based on a project sent by a friend on Whatsapp!

But in use, I found it massive, not very practical, not very pretty… in short, not adapted to my needs.

Except that (I’ve already mentioned it) I’ve since gotten into 3D printing and a bit (by force of circumstance) into 3D modeling (they often go hand in hand). I said to myself: why not create my own project that fits my needs?

So I wanted to explore a homemade solution for my homelab, 3D printed, that would be both modular and stackable. The idea was to offer an adaptable system according to needs, with a simple and effective design.

A design designed for organization

The MicroStack Rack is designed to neatly store several Dell OptiPlex Micro while maximizing space. It consists of three different modules for now:

The PC module, which accommodates a Dell Micro (all generations) and its external power supply at the back for more practicality.

The storage module, an empty compartment for accessories, network switch or other equipment.

The hat, an optional element that covers the rack for a cleaner rendering.

All modules are stackable, allowing you to adapt the configuration according to your number of machines.

Even though I printed the prototype in PLA, I recommend using PETG instead, which resists heat better than PLA. However, these machines remain rather cool at idle and the honeycomb floor improves ventilation (and reduces material consumption). Maybe it works too.

How long does it take to do this kind of project?

A quick note on time spent.

I haven’t done much 3D design in the past (I made a few maps on Unreal Tournament 2004… oh my…, that was 20 years ago!!!). So, I thought it might be interesting to share how long it took me.

The modeling was done in three sessions of 2 hours:

2h to take measurements, make an initial prototype and get familiar with Blender.
2h to create the module dedicated to the Dell Micro.
2h to add the storage module and the hat (it goes faster, I’ve already done part of the work and I’m more efficient in my use of Blender).

We can add an hour or two for handling the 3D printer (launching the print, checking it doesn’t fail a few minutes in, cleaning the plate after printing, etc.) and 3-4 hours for the “social” part (photos, upload to makerworld, writing descriptions and blog post, sharing on social networks).

A nice little side project of about ten hours then.

Files and evolutions

As promised on Bluesky where I teased the project, the files were created under Creative Commons 4.0 BY-SA license (STL formats and Blender sources), but this is incompatible with MakerWorld exclusive policy (obviously) so the 3MF files are in Standard Digital File Licence:

A version compatible with Lenovo ThinkCentre Tiny is planned for the future (I was asked on Bluesky).

If this project interests you, feel free to comment, share, provide feedback, or even boost the three models for those who have a MakerWorld account (it’s free, but it’s appreciated :-P).

Sidero Omni - Talos Linux on Oracle Cloud (free tier)

Sat, 04 Jan 2025 18:00:00 +0200

Fun fact, on January 4th, 2024 (exactly one year ago), my first article of the year was about Maas. Starting 2025, on the same day, with another article about a solution that aims to automate infrastructure, especially bare metal, is funny :)

Context

I won!!!

I occasionally play games on social media (less often now) and I also sometimes enter contests at conferences.

And there, I won a one-year subscription to Sidero Labs’ SaaS (the creators of Talos Linux), Omni.

For those wondering, Omni is a Kubernetes cluster deployment solution that allows you to orchestrate servers running Talos, a minimalist and secure Linux operating system dedicated to Kubernetes. As for Talos, we’ll certainly talk about it in future articles.

What Does This Have to Do with Oracle Cloud?

Winning is great, it’s always nice. But what do I do with this SaaS now?

The first idea that comes to mind is to order a dedicated server somewhere and install Talos on it (with an ISO generated by Omni), or do the same thing but install a hypervisor, then create Talos Linux VMs (again, thanks to Omni).

But I’m ~~cheap~~ eternally frugal and I saw that Oracle Cloud Infrastructure (OCI) is supported by Talos Linux and Omni, so I wanted to try it.

For those who don’t know OCI, I wrote a series of articles in 2023 explaining how to create a free cluster with kubeadm on the (quite generous) free tier:

We’re going to reuse the free tier here, but to deploy and manage clusters with Omni.

Note: you can reread them, but I’ve done better since then because I managed to integrate free tier machines INTO a managed Kubernetes cluster, which is much nicer to use. Stay tuned for the upcoming article ;).

Prerequisites

For Talos Linux on Oracle Cloud Infrastructure (OCI) and more specifically integrating machines with Omni, there are a few necessary configuration steps.

Note: this tutorial is partially based on the official Talos Linux documentation, adapted for Omni and with additional details on Oracle Cloud Infrastructure.

I’m assuming you already have an account on Oracle Cloud Infrastructure, as well as the talosctl binaries and the oci CLI. Otherwise, a quick:

brew update && brew install oci-cli talosctl

Authenticate with the CLI tool:

oci session authenticate

When authentication is requested, choose the region corresponding to your location (for example, eu-paris-1). Once done, you’ll see a confirmation message in the browser and you’ll need to give a cute name to the profile for oci in the terminal and validate.

Retrieving the Compartment ID

One of the interesting concepts of Oracle Cloud Infrastructure (found in other cloud providers in one form or another) is the notion of “compartment”. Basically, resources are stored in “compartments” to organize resources.

You can work in the “root” compartment, but it’s cleaner to create a specific one for the occasion.

Example OCID:

ocid1.compartment.oc1..aaaaaaaayrmiilkb5m2b7never345435gonna345give87978you12upu6ifoh6csihm4awsjq

Preparing the Oracle Cloud Environment

Once we have that, we’ll use the CLI to create all the things we’ll need for our virtual machines to register on Omni’s SaaS.

Creating a VCN (Virtual Cloud Network) and network configuration:

export cidr_block=10.0.0.0/16
export subnet_block=10.0.0.0/24
export compartment_id=<your_ocid_compartment>

Create the VCN and subnet:

export vcn_id=$(oci network vcn create --cidr-block $cidr_block --display-name talos-example --compartment-id $compartment_id --query data.id --raw-output)
export rt_id=$(oci network subnet create --cidr-block $subnet_block --display-name kubernetes --compartment-id $compartment_id --vcn-id $vcn_id --query data.route-table-id --raw-output)

After the 2nd command, we retrieve not the OCID of the subnet (we don’t need it), but that of the “Route Table”, a subcomponent of the subnet, which allows defining the routing table of the subnet we just created.

Configure a gateway (Internet Gateway):

export ig_id=$(oci network internet-gateway create --compartment-id $compartment_id --is-enabled true --vcn-id $vcn_id --query data.id --raw-output)

Add a routing rule (to our route table) to allow Internet access:

oci network route-table update --rt-id $rt_id --route-rules "[{\"cidrBlock\":\"0.0.0.0/0\",\"networkEntityId\":\"$ig_id\"}]" --force

Disable default firewall rules (YOLO):

export sl_id=$(oci network vcn list --compartment-id $compartment_id --query 'data[0]."default-security-list-id"' --raw-output)

From there, we have the functional network part, ready to host our machines!

But It’s Not Over Yet :-/

With Oracle Cloud Infrastructure, it’s possible to boot a list of predefined OSes, but in our case, Talos Linux is not on the list.

Fortunately, Omni will generate a preconfigured virtual disk with our credentials, which will allow us to enroll Talos Linux servers to our Omni SaaS from the first boot. Classy 😎.

So we connect to our Omni interface and download the appropriate Talos Linux image:

Here, I chose version 1.9.1 (the very latest because we like danger), for amd64 architecture. I retrieve the image oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz which I decompress:

xz --decompress ./oracle-amd64-omni-zwindler-v1.9.1.qcow2.xz

Reminder: OCI’s free tier consists of:

2 amd64 machines with 1 oCPU (= vCPU) and 1 GB of RAM each
a flexible combination of arm64 instances having 1 x n oCPU and 6 x n GB, as long as the total doesn’t exceed 4 oCPU (and therefore 6x4 = 24 GB of RAM).

On OCI, there are several formats for importing disks. The simplest is to use OCI’s “homemade” format (the .oci, super original name), which consists of a metadata file and the QCOW2.

Create the metadata file for import, with the VM.Standard.E2.1.Micro shape since we have an amd64 image (otherwise it’s VM.Standard.A1.Flex):

cat > image_metadata.json << EOF
{
 "version": 2,
 "externalLaunchOptions": {
 "firmware": "UEFI_64",
 "networkType": "PARAVIRTUALIZED",
 "bootVolumeType": "PARAVIRTUALIZED",
 "remoteDataVolumeType": "PARAVIRTUALIZED",
 "localDataVolumeType": "PARAVIRTUALIZED",
 "launchOptionsSource": "PARAVIRTUALIZED",
 "pvAttachmentVersion": 2,
 "pvEncryptionInTransitEnabled": true,
 "consistentVolumeNamingEnabled": true
 },
 "imageCapabilityData": null,
 "imageCapsFormatVersion": null,
 "operatingSystem": "Talos",
 "operatingSystemVersion": "1.9.1",
 "additionalMetadata": {
 "shapeCompatibilities": [
 {
 "internalShapeName": "VM.Standard.E2.1.Micro",
 "ocpuConstraints": null,
 "memoryConstraints": null
 }
 ]
 }
}
EOF

And then create the image for import:

qemu-img convert -f raw -O qcow2 oracle-amd64-omni-zwindler-v1.9.1.raw oracle-amd64-omni-zwindler-v1.9.1.qcow2
tar zcf oracle-amd64-omni-zwindler-v1.9.1.oci oracle-amd64-omni-zwindler-v1.9.1.qcow2 image_metadata.json

Importing the Image to Oracle Cloud

We have the file ready to be uploaded… but where do we upload it??

Unfortunately, this step is done in 2 parts. First, you need to upload the .oci file to a bucket. It’s quite simple to do in the UI (we could also do it via CLI):

Create a bucket in the Storage section to upload the compressed image.
Upload the image (oracle-amd64-omni-zwindler-v1.9.1.oci) to this bucket.

Second step, we transform the file into “Custom images” (in the Compute section):

This step is oddly quite long, the image which is only 100 MB took 10 minutes each time I tried so far.

Creating the VM

Once the image is imported, we can now use our Omni-customized image to boot our free tier machines.

I also did this through the OCI interface, but again, we could do it via CLI.

A few seconds after boot, it appears in Omni’s UI and can be added to a cluster.

Have fun!!

Addendum: Is It Really Free?

Yes…-ish.

In theory, the machines are free (forever free as they say). But beware, lots of little things can be paid.

For example, the bucket where we uploaded the QCOW2/.oci is most likely paid. Same for the custom image, which is billed as 1 GB of storage (according to the UI, I don’t have the bill yet LOL).

If you put the VMs behind a load balancer (there’s no reason you’d do that here), be careful, only the “non-flexible” LB capped at 10 Mbps is free (and only one).

And if like me, you already have 4 x 50 GB disks, the OS storage is paid (€1.85 / month).

In short, as you’ve understood, it’s like often in the cloud, nothing is really free and you have to read all the fine print.