When I started the netlab project, Vagrant was the go-to tool if you wanted to build a virtual environment described in a text configuration file (an idea popularized as infrastructure-as-code). It wasn’t ideal for what we were doing, but a tool rarely does a great job when used far away from its intended use case.

netlab initially supported Vagrant with VirtualBox, quickly adding support for KVM/libvirt through the vagrant-libvirt plugin. Life was good… until it wasn’t.

In 2023, HashiCorp changed its Vagrant license. I don’t know whether that impacted the development of the vagrant-libvirt plugin, but the last release was published in June 2023, and the last PR was merged in December of the same year. Some of the bug fixes thus never made it into a release, and the project currently has over 30 open pull requests; the plugin looks like another sad case of abandonware.

The Vagrant license change obviously left a bad taste. For example, with release 24.04, Canonical stopped publishing Ubuntu boxes (we used Ubuntu as the base box for FRR). Still, there were third-party boxes one could use.

The other shoe dropped in July 2026: HashiCorp decided to kill Vagrant Cloud (the public image repository) by the end of 2026. It was time to part ways; netlab is sunsetting the libvirt provider and will rely primarily on containerlab for workload orchestration.

Don’t panic if you’re relying on the netlab libvirt provider (and invested time in building a large collection of Vagrant boxes). It’s not going anywhere, and we’re not removing anything from the codebase (just yet). We’ll fix any bugs that come up, but we won’t add new libvirt features or run device integration tests with it. For the moment, libvirt tests will also remain part of the platform integration tests to catch any breaking changes. I’ll probably do a code cleanup a year or two from now, after checking that all the supported platforms work well with vrnetlab.

In the meantime, I’d encourage you to build vrnetlab containers for the devices you’re using (it’s usually a pretty straightforward process) and report any potential problems to the vrnetlab team; they are usually very responsive.