Blogs

For those familiar with OpenShift, the power and convenience of its templating engine are well-known. It allows users to define, customize, and reuse application definitions with ease. The KubeVirt community could greatly benefit from a similar mechanism that works on any plain Kubernetes cluster.

To that end, I have authored an enhancement proposal to introduce a native templating engine into KubeVirt. The proposal, tracked as VEP 76, details the design for making VirtualMachine templating a first-class citizen in the KubeVirt API. The goal is to provide a declarative way to manage complex VM specifications, reducing boilerplate and simplifying automation.

This new feature is designed to be extensible, with future plans to include import and export capabilities using the industry-standard Open Virtualization Format (OVF/OVA). This will make it even easier to share and manage templates across different environments and teams.

The implementation for this enhancement started at github.com/0xFelix/virt-template. This project will soon be moved to the KubeVirt organization at github.com/kubevirt/virt-template as it matures.

A native templating engine will significantly improve the user experience for the KubeVirt community. I invite you to review the enhancement proposal, check out the implementation, and join the discussion to help shape the future of VM management in Kubernetes.

My talk for CloudLand 2025 about GitOps, Infrastructure as Code (IaC) and KubeVirt was accepted! You can find the slides of the talk here.

It will take place on the third day of CloudLand 2025 (2025-07-03) as part of the Compute / Storage / Network track in the Schatzinsel room at 17:00 CEST.

Go here for more information about my talk. The talk is going to be recorded and will be available for all attendees. The talk will be held in German language.

A little late, but my talk for DevConf.CZ 2025 about KubeVirt’s CLI (virtctl) and its Ansible bindings (kubevirt.core) was accepted!

It took place on the first day of DevConf.CZ 2025 (2025-06-12) in the Cloud, Hybrid Cloud, and Hyperscale Infrastructure track at 15:30 CEST.

Go here for more information about my talk. You will also find a recording of the talk there.

I have written the hetzner-dnsapi-proxy utility to forward requests to a small number of known DNS APIs to the Hetzner DNS API. This is useful if you have a device on a private network and want to create a valid TLS certificate with LetsEncrypt.

In addition, Hetzner does not provide granular access control for its API, so another benefit of the proxy is that it gives you control over which DNS records can be updated on a per-user basis.

The supported APIs are:

• lego HTTP requests
• acme-dns
• DirectAdmin (legacy API)
• Plain HTTP requests with query parameters

You can find the project and more information about it here.

My talk for FOSDEM 2025 about KubeVirt’s CLI (virtctl) and its Ansible bindings (kubevirt.core) was accepted!

It will take place on the second day of FOSDEM 2025 (2025-02-02) in the Virtualization and Cloud Infrastructure room at 13:00 CET.

Go here for more information about my talk. You will find a link to the live stream there. The talk is also going to be recorded.

I’m running TrueNAS Scale on an offsite server to backup my data and I’m using the native encryption of ZFS to securely store it at rest.

To periodically backup my data to the offsite server with an automated script, I needed to find a way how to unlock the ZFS datasets from the command line, while not messing with the way TrueNAS Scale manages the storage.

Enter midclt, a tool to access the TrueNAS Scale REST API from the command line. With midclt call you can call all of the described API endpoints, without creating an API token or the need to call the API externally.

After discovering midclt and the API reference, I needed to figure out how this works. I couldn’t find any docs on the topic, but eventually, I was able to make it work.

How midclt works#

The first argument to midclt call will be the name of the endpoint, for example pool.dataset.unlock.

Many API endpoints take an id, which will be the second argument to midclt call.

If the endpoint takes additional options, those can be supplied as a JSON string as the third argument to midclt call, like so:

Welcome to my new website, I hope you like it! I have created this site to share some thoughts and write about things I encounter in my daily life as a software engineer, or when I’m hacking on stuff in my spare time.