Management Network Adapter Now Mandatory in vagrant-libvirt

Introduction

I will share a trouble associated with the update of vagrant-libvirt.
Those considering an update, please take note of the following points.

Vagrant uses a management network (NW) for managing virtual machines.
The management NW is connected via a NAT adapter that is automatically generated when the virtual machine is created.
NAT adapters are easily recognized as eth0, which had compatibility issues with software that uses eth0 for communication as a fixed setting.

In the old fog-libvirt plugin, the vagrant command functioned even if the NAT adapter was deleted.
On the other hand, in the new fog-libvirt plugin, deleting the NAT adapter causes the vagrant command to stop functioning, requiring adjustments to the NW settings.

Target Audience

• Those who use vagrant-libvirt for virtual machine management
• Those who are considering updating vagrant-libvirt

Prerequisite Environment

It is important to note that updates are linked together in a sequence: Vagrant update -> Ruby update -> Vagrant plugin update.

• Old environment: Vagrant v2.2, Ruby v2.5, fog-libvirt v0.8.0
• New environment: Vagrant v2.4, Ruby v3.3, fog-libvirt v0.14.0

Troubles Accompanying the fog-libvirt Update

Phenomenon

If you specify mgmt_attach => false and do not generate a management NW adapter, or if you delete the management NW adapter after the virtual machine is created, the following error occurs when executing the vagrant command.

Fog::Errors::LibvirtError: Call to virNetworkLookupByName failed:
Network not found: no network with matching name 'vagrant-libvirt'

Due to this error, the vagrant command will no longer function.

Cause

With the update of fog-libvirt, it has become a prerequisite that the management NW adapter exists when vagrant-libvirt operates the virtual machine.

Therefore, if the management NW adapter is deleted as was previously possible, virNetworkLookupByName("vagrant-libvirt") executed internally by fog-libvirt fails, and Vagrant cannot recognize the VM, resulting in an error.

Countermeasure

Although the management NW adapter cannot be deleted due to the requirements of fog-libvirt, the NIC recognition order in Linux depends on the PCI bus and slot number order.

Therefore, by shifting the PCI slot number of the management NW adapter further back, it is possible to have the OS recognize the custom network adapter first and treat it as eth0.

Referring to the official documentation below, specify the bus and slot for the management NW adapter in the Vagrantfile.
https://vagrant-libvirt.github.io/vagrant-libvirt/configuration.html#management-network

Vagrantfile

management_network_pci_bus = '0x00'
management_network_pci_slot = '0x09' # Set a large value

Conclusion

Applications with dedicated plugins, such as Vagrant, may stop functioning due to changes in plugin specifications, even if the application's own specifications remain unchanged.

We use plugins because they are convenient, but the risk associated with updates increases with the number of plugins being used.

This time, I realized once again how important it is to use them while understanding these trade-offs.