This installation used to work but has broken through ipfire upgrades.
I am now at ipfire 2.29 core update 193.
I have a virtual machine that won’t start because the network configuration can’t be resolved.
I have installed
libvirt-10.10.0-38
qemu-9.2.0-45
I saw another community post recommending installing qemu-ga but that is the guest agent. The ipfire is running directly on the hardware so no guest agent is required.
I can connect virt-manager (running on Ubuntu 24.04) to libvirt (on ipfire) and I can interact with the virtual machine configuration.
When I attempt to check network configuration in ipfire using ssh command line:
virsh net-list
error: Failed to get the number of active networks
error: this function is not supported by the connection driver: virConnectNumOfNetworks
I have tried removing and reinstalling the libvirt and qemu addons but this has not changed the situation. I can’t figure out a network configuration that will allow the virtual machine to start.
The virtual machine is to host the UniFi controller for my access points, so it must be connected to the blue network to perform it’s function.
How can I configure the networking correctly to allow the virtual machine to be started?
To support my unifi network, I just need the following:
PoE switch connected to Blue on ipfire
UniFi access points connected to PoE switch
unifi software connected to blue network to manage the access points.
The unifi software is installed inside the KVM virtual machine.
Everything is in place, and has worked before with earlier versions of ipfire. The only thing that is broken is the VM network connection to the blue port in Bridge mode.
So I’m asking for help to get the VM connected to the blue network port.
I’m sorry I can’t give a useful answer to this question. As best I can figure it last worked between 1yr to 1.5yrs ago. This puts it around ipfire core 180 - 185.
The system was not working when I found it at core 190, and I upgraded it to 193 and it still does not work. Note that I had to update the libvirt and qemu addons separately from updating the core.
Unfortunately I think we must diagnose this from first principles.
I could attempt to create a new virtual machine (re-using the same disk image).
Taking CU180 as the last time it worked I have looked at the version updates over that period (from Oct 2023) for both qemu and libvirt.
qemu went from version 8.1.1 to 9.2.0 - covering 25 version updates.
libvirt went from version 8.10.0 to 10.10.0 - covering 22 version updates.
I have searched through the changelogs for all those versions and could not find anything about bugs to do with the bridge mode or any changes in how that network connection mode works.
So there is nothing obvious from the changelogs suggesting anything that would cause what you are describing.
Then we will need to look for a user that actually uses libvirt/qemu on IPFire.
I can’t help with that as I have never used libvirt or qemu on or off IPFire.
Reading through the IPFire libvirt documentation, it looks like it was originally created at least 4 years ago as it refers to the use of macvtap which was removed in CU156.
The documentation has a note about this change and says to use bridge instead of macvtap but nothing has been changed in the detailed instructions and it is not clear to me if just changing all macvtap to bridge is sufficient or if a modification is also required in the main description.
Hopefully one of the users actively using libvirt on IPFire will update the documentation.
I have not used libvirt on IPFire for a couple of years. I abandoned it for much the same problem OP is having - could not get it to set up two virtual NIC for red0 and green0.
I’ve reverted to using openSUSE as a host and started using virt-install, that is a command line installer for VM. It allows virtually any supported option for a VM to be invoked. It does require a minimum of 8 parameters for a VM to be defined. If virt-install is included in IPF then that might be a solution
My theory is that some required option has been omitted when libvirt was compiled for ipfire (refer error message when attempting to list networks by virsh).
At the moment I’m looking at solving my issue by hosting the virtual machine somewhere other than ipfire.
The compile options haven’t been changed since CU164 when libvirt-7.10.0 was added. This had to change the autotools build using configure to a meson/ninja build system as libvirt stopped using autotools in version 6.7.0.
All existing configure options had equivalents found in the meson options except for three
--with-virtualport
--with-macvtap
--without-dbus
These were no longer supported by libvirt since 2020.
the macvtap option was no longer relevant as macvtaps were removed from IPFire in CU156.
The change from autotools to meson/ninja was done in CU164, three years ago.
If --with-virtualport refers to “virtual network interface” from the meson option driver_network then this is enabled automatically by meson if supported.
I would need to check the logs of an IPFire build to see if this is supported or not. I will do this later next week as I am not able to do anything currently.
Doing searching related to virtualport and libvirt I have not been able to find anything that indicates that this is the equivalent to the virtual network interface.
It would be good if someone else could see if they can find any references, especially in the move from autotools to meson ninja in libvirt back in 2020.
If this option is the one causing the problem then it means that your last working version was not somewhere in CU180 to CU185 but CU164 or earlier.
It would also be good if an actual libvirt user would pick up the IPFire update actions when new versions are released. They would then have knowledge of the actual use, which I don’t.
Looking back through the versions when meson was first changed to I found that the --without-dbus option became removed as libvirt stopped using the libdbus option and used the dbus functionality from glibc. Iit was available in the initial change to meson in 6.7.0 but was then removed in libvirt-6.8.0.
I also found that in the initial meson change in 6.7.0 with-virtualport was present in the meson options as well as the “virtual network interface” so those two options are separate.
The virtualport option in the meson build was removed by libvirt in version 6.9.0 but it is not mentioned in the changelog at all.
However if libvirt removed that option in the meson build and did not replace it with anything suggests it was deprecated and not needed for anything anymore or that it has been built in as a default standard option. I haven’t been able to determine which of these are the actual situation.
EDIT:
I have found referenced in the libvirt documentation and it has references back to version libvirt-0.8.2 and still referenced for current versions.
So it looks like the ability to disable virtualport has been removed and it has been made a default core function since libvirt-6.9.0
So we really need an IPFire user that uses libvirt actively and successfully to report back on how they have achieved their setup.
Have found the commit in the libvirt source code that removed the virtualport option from the meson options.
Basically it was a useless option as all it did was check if the build was on Linux and that IFLA_PORT_MAX was defined in linux/if_link.h.
As the IFLA_ stuff was added into the kernel in version 2.6.32, which is very old, then the virtualport option was checking for something that did not need to be checked for anymore.
So it has nothing to do with the interface issues you are experiencing.
