Weeks 5 and 6 were all about making the code production-ready. This period was characterised by three key themes: performance validation, improvements to the build system, and the art of breaking down large PRs into manageable or reviewable chunks. Let me walk you through the transformation phase, which will ultimately determine whether my GSoC project is accepted into the main Lima codebase.

Build System

The first big milestone was to configure the Makefile correctly. To be honest, build systems were entirely new to me, and I spent a significant amount of time studying about Make.

The aim was straightforward: by default, all drivers should be constructed as internal (the usual manner), but users should also be able to convert individual drivers to external mode.

# Default build all drivers internal
➜ make limactl
➜ limactl create --list-drivers
qemu
vz

# Making specific drivers external
➜ make EXTERNAL_DRIVERS="vz" limactl
➜ limactl create --list-drivers   
qemu
vz(external)

# Making multiple drivers external
➜ make EXTERNAL_DRIVERS="qemu vz" limactl
➜ limactl create --list-drivers
qemu(external)
vz(external)

Later, I refined this approach based on feedback and changed the terminology from EXTERNAL_DRIVERS to ADDITIONAL_DRIVERS to better reflect what was happening:

make ADDITIONAL_DRIVERS="qemu vz" limactl additional-drivers

This configuration system was crucial because it allowed the team to maintain backwards compatibility while enabling easy testing of the plugin system. I also modified the parenthesised information about drivers to show the location using limactl info.

Benchmark The New Plugin System

One of the most important criteria was that the plugin system didn't cause performance regressions. This involves doing extensive benchmarking using real-world circumstances.

My approach:

Establish baseline metrics using the master branch
Run identical tests on my feature branch with drivers being internal and external
Compare results to ensure no performance degradation
Document findings for the team

I chose iperf3 as the benchmarking tool and focused on TCP port forwarding performance because currently there is some issue with the UDP port forwarding. The setup involved running iperf3 server on the guest VM and client on the host, measuring throughput across different scenarios.

Here is the page that contains all the benchmark data.

The Zoom Meeting Showcase

I had the chance to share my work with my mentors via a Zoom call on June 26th. Although the presentation went smoothly, there was a little mishap that perfectly illustrated the challenges of working remotely on development projects. The benchmarks I ran during the Zoom session produced much less than I had anticipated:

# During Zoom session - noticeably slower
➜ iperf3 -c 127.0.0.1 -p 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  1.84 GBytes  1.58 Gbits/sec                  sender
[  5]   0.00-10.01  sec  1.84 GBytes  1.58 Gbits/sec                  receiver

I was initially worried something was wrong with my implementation, but after ending the Zoom session, the numbers jumped back to normal:

# After Zoom session - back to normal performance
➜ iperf3 -c 127.0.0.1 -p 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-10.00  sec  2.49 GBytes  2.14 Gbits/sec                  sender
[  5]   0.00-10.00  sec  2.48 GBytes  2.13 Gbits/sec                  receiver

This was a perfect example of how resource-intensive video conferencing can impact system performance - something to keep in mind for future benchmarking sessions!

Key Feedback from the Meeting

🎉 Good News: My mentors were pleased with the overall strategy and benchmark results. It was a great relief that no performance regressions were found.

Important Insights:

UDP forwarding was apparently broken in the master branch already, so any UDP issues weren't regressions from my work
The image downloader needed to be moved to the main binary to show download progress properly
Windows support was optional but encouraged
The critical deadline was getting ready-to-merge PRs submitted before the mid-term evaluation(~ July 15 - July 20)

The Splitting of the Big PR

At this point, things became both extremely intriguing and difficult. I needed to divide my weeks-long pull request into manageable, reviewable sections. I had never encountered this degree of Git complexity before, and I gained a great deal of knowledge about complicated Git processes.

The splitting strategy involved:

Creating separate branches for different logical components
Using git cherry-pick to selectively move commits
Ensuring proper dependency relationships between PRs
Managing merge conflicts and rebasing

Branch Organization

refactor/basedriver - Core driver abstraction work
feature/driver-registry - Driver discovery and registration
feature/internal-driver-system - Internal driver implementation
feature/external-driver-system - External driver plugin system

The Challenge of Dependencies

The trickiest part was managing dependencies between PRs. I ended up with four PRs that needed to be merged in a specific order:

Because PR-2 needed to import packages that would only be accessible after PR-4 was merged, managing dependencies became challenging. I had to carefully plan the merge sequence and temporarily negate imports.

Windows Error

Windows support continued to be a source of interesting challenges. I managed to get Lima running on Windows with internal drivers working, but external drivers were having discovery issues with the lima-driver-wsl2 executable.

The main issue I encountered was related to symlinks not being supported on Windows:

texttime="2025-07-09T03:22:30+05:30" level=fatal msg="unable to load instance wsl2: open C:\Users\Ansuman Sahoo\.lima\wsl2\lima.yaml: The system cannot find the file specified."

This led me to discover that only the experimental/wsl2 template was working reliably on Windows, which makes sense given the symlink limitations and the different filesystem characteristics of Windows.

Current Status and Next Steps

As I write this blog post, three out of four PRs have been successfully merged into the main Lima codebase! This seems like a significant milestone; seeing weeks of effort really become part of the official project and others around the world will utilise it in their workflow is what motivates me to continue contributing to open source more.

The external driver PR still needs some fixes, but we're close to having the complete plugin system available for the Lima community.

What's Next:

Fix the Windows issue
Move driver-specific codes from pkg/limayaml to drivers (this will be the most complex part)
Accelerate GuestAgentConn performance and implement additional drivers like krun and vbox

Looking Forward

With the core plugin system nearly complete, I'm excited to move into the next phase: refactoring existing driver code and exploring advanced optimisations. The foundation is solid, and now it's time to build on it.

The plugin system is no longer just a concept - it's becoming a reality that will enable the Lima community to extend the platform with new VM drivers. That's exactly what GSoC is about: building something that will have a lasting impact.

Stay tuned for the next update as we dive into the driver refactoring phase, start exploring some of the cool AI integrations via krun and new driver implementations!

GSoC Week 5 & 6: Advanced Git, Build Systems, and Windows Challenges

Table of contents