Blog

The OpenSFF Dev Team

April 10, 2026

Development Update

Management Module Software Development Update #3

Introduction

OpenSFF console session — A console session on the management web interface (work in progress). Image by OpenSFF.

We’ve made a lot of progress on the Management Module software since our last dev update, including significant improvements to the quality and responsiveness of the VNC server’s output. We’ve also refined the web interface, created lots of new endpoints, and squashed many bugs along the way.

The team also settled on a couple of significant changes: we revisited how Compute Node information reaches the Management Module, and separated console sessions from power controls. These decisions and the results of our testing led to notable changes to all three of our specifications, which will be reflected in their next update. There’s a lot to go over, so let’s dive in.

Backend changes

Replacing hw-info with noded

When we were putting together our test hardware, our hardware engineer and software developer Carlo Jones created hw-info. It’s a Rust crate that the Node API was supposed to use to get information about installed Compute Nodes. We could then display those data on the appropriate Node page on the web interface.

OpenSFF management interface old Node page — An old version of the Node page that used hw-info to display “node” stats. Image by OpenSFF.

During our testing, we realized that the crate was reporting the specs of the system it was running on. In production hardware, that would be the Management Module itself. This clearly wasn’t our goal, and that information should only be available to platform administrators, not node admins. So we started working on noded, an optional daemon that can be installed on Compute Nodes.

Besides displaying node hardware information on the web interface, we also plan for noded to support event logging and backing up Compute Node configuration files. Those configuration files will streamline node replacements. We’re also exploring whether OS provisioning and storing node encryption keys are within the scope of noded.

Separating console sessions from power controls

This is perhaps the most impactful change since our last update. It resulted in changes in both the Management Module’s software and its hardware specifications. In our original design, KVM access and power controls were part of the same flow. When a user picked a node on the Node selection page, they would automatically initiate a console session on that node.

However, our specification developer Jon Choi realized that we needed to add components on the Enclosure to detect the power state of installed Compute Nodes, along with several new pinout assignments.

OpenSFF Enclosure KVM and power control architecture — The new KVM and power control architecture in managed multi-node Enclosures. Image by OpenSFF.

Since we were splitting up the KVM and power state components, we decided to split up their controls as well. This way, an admin can toggle the power of one node while they’re on another node’s console. We’ll take a closer look at the new architecture and its related changes in our next Management Module hardware dev update.

Virtual media functionality

Some of the Node API endpoints that lead developer Aldrin Bobita created since our last update enable mounting and managing ISO files. Both admin types can upload such files, which would then be kept in the Management Module’s internal storage. Platform admins have no file size restrictions, but they can set total file size limits for node admins. Platform admins can also designate an image file as “public”, allowing all admins to access that file. Only one image can be mounted at any given time.

OpenSFF management interface Configuration page node admin settings — The node admin settings on the Configuration page (work in progress). Image by OpenSFF.

USB emulation

Carlo updated the gadget script on the Management Module server to merge the absolute and relative mouse descriptors into one function. Christian then merged the corresponding device files into one mouse file handle on the usb-emulation crate. Absolute and relative mouse reports are now sent over the same HID gadget device, but they each have their own report ID prefixes. We’ll also add a setting on the web interface that will allow users to switch between the two mouse modes.

Minimizing required Enclosure metadata

While we’re still working on a way to display Enclosure information on the web interface, Jon already pointed out that we don’t want to require lots of metadata from Enclosure vendors. As such, the only Enclosure metadata the Management Module requires is the number of Compute Node slots on the Enclosure.

If an Enclosure’s configuration file contains additional information such as model name, slot name, or a layout diagram, we can display those in the web interface. But the Management Module will work without any of that data. This should also make it easier for users to fully utilize secondhand managed Enclosures, even if they don’t have the original Enclosure configuration files.

VNC server performance

Our original V4L2 MJPEG decoding used jpeg_decoder and a custom RGB conversion function. Our developers Ivanne Bayer and Christian Gantuangco found a consistent ~500ms delay in this path. To fix this, they switched to turbojpeg, which handles JPEG decoding and pixel format conversion in a single step. That brought the average server-to-client message cycle down from ~600ms to ~70ms, along with noticeable improvements to image quality.

OpenSFF JPEGdecoder VNC test — The video output of the previous MJPEG decoding process. Image by OpenSFF.

OpenSFF Turbojpeg VNC test — The video output of the turbojpeg decoder (work in progress). Image by OpenSFF.

In terms of message handling, the original server ran a single loop that processed keyboard input, mouse input, and framebuffer update requests together. However, the framebuffer stalled when the client sent a lot of mouse events. Every reader_task had to await its handler before it could process the next input. Christian’s fix involved a custom HID event queue implementation for parallel pointer and key events.

Christian also made several improvements on the encoding front. Previously, the server created a new instance of ZrleEncoder on every encode_rectangle call. He refactored the code so that the encoder would persist across calls instead. Christian also added solid tile detection to ZRLE:tiles. This compressed the pixel data down to a few bytes, reducing both bandwidth and Zlib CPU usage. He also optimized Hextile encoding, reducing the amount of bytes sent per frame for a fullscreen window from over 3MB to less than 1MB. Christian also added support for CopyRect encoding to the backend.

At this point, our VNC server handles most workloads well. Terminal sessions and web browsing feel responsive at 1080p on ~60ms ping. We’re working on improving performance further, particularly during continuous video playback at high resolutions. While we’re not targeting video playback as a use case at this point, we’re aware that such content can play incidentally during normal use, such as when a video ad pops up while browsing.

Frontend changes

Aside from helping with the VNC server, Ivanne also connected the new backend endpoints to the frontend. He also made several rounds of changes to the web interface.

OpenSFF management interface log in to KVM Screen user flow — Opening a console session on the web interface (work in progress). Image by OpenSFF.

The navigation bar is now consistent across the whole interface, with an OpenSFF logo on the top left followed by context-sensitive text, such as “Setup” for configuration pages related to the Management Module and “Node #N” (or the selected node’s configured name) for Node pages.

The Node selection page now has a search bar and can be paginated. Platform admins see all Compute Nodes connected to the Management Module, while node admins see only their assigned nodes.

OpenSFF management interface Node selection page — The Node selection page (work in progress). Image by OpenSFF.

After the admin selects a node on the Node selection page, they will land on the corresponding Node page. The Overview tab on that page shows node information.

OpenSFF management interface Node page Overview — The Overview tab on the Node page (work in progress). Image by OpenSFF.

The Advanced tab is visible only to platform admins. It shows the power and network states of the selected node.

OpenSFF management interface Node page Advanced — The Advanced tab on the Node page (work in progress). Image by OpenSFF.

The Controls tab lets users toggle the selected node’s power and adjust hardware settings such as fan speed.

OpenSFF management interface Node page Controls — The Controls tab on the Node page (work in progress). Image by OpenSFF.

When users select the KVM Screen tab, they’ll be prompted to either connect to the node’s console or go back to the Node page. If someone else already has the console, the KVM Screen will instead inform the user accordingly.

OpenSFF management interface platform admin Configuration page — The platform admin’s Configuration page (work in progress). Image by OpenSFF.

On the Configuration page, platform admins and node admins now see different versions of the Network and User Management settings. In the Network settings, platform admins can set a node’s IP address to be configured via DHCP or static IP, while node admins can only view the current setting.

OpenSFF management interface platform admin Network settings — The platform admin’s Network settings on the Configuration page (work in progress). Image by OpenSFF.

The Reboot Schedule settings are now restricted to platform admins.

OpenSFF management interface platform admin Reboot Schedule settings — The Reboot Schedule settings on the Configuration page (work in progress). Image by OpenSFF.

On the User Management page, node admins can see their assigned node IDs and user information, while platform admins can create additional platform admin and node admin accounts.

OpenSFF management interface platform admin User Management settings — The platform admin’s User Management settings on the Configuration page (work in progress). Image by OpenSFF.

Ivanne also connected Aldrin’s virtual media endpoints. The ISO Settings lets admins add ISO files or delete the ones they added.

OpenSFF management interface platform admin ISO settings — The ISO settings on the Configuration page (work in progress). Image by OpenSFF.

Admins can then mount or unmount available image files while on a console session.

OpenSFF management interface KVM Screen ISO mounting — Mounting an ISO on a console session (work in progress). Image by OpenSFF.

Integration testing

OpenSFF management module development environments — A summary of our Management Module development environments.

The team ran end-to-end tests on Dev Environment 1. Node switching, console sessions, power controls, and ISO image uploading and mounting all worked as expected. We’re going to continue testing on both of our test hardware setups, though we have an outstanding issue with node switching on Dev Environment 2.

Build with OpenSFF

We still have a long way to go, and we’re excited to work on our design changes. Aside from more optimizations to the VNC server, our immediate goals also include finishing noded, rounding out the Node API, and creating a media writer that will allow users to configure and flash the Management Module software to an SD card or USB drive. We’re also exploring how we can minimize the size of the software’s distribution image.

Join us again on our next update. We encourage you to read our specifications, and we’d be grateful if you spread the word about OpenSFF. For technical clarifications and other inquiries, reach out to our development team at [email protected].