Remove of macvtab in core update 156

Hi @ all.

I just looked at the changelog for the upcoming core update 156 and saw that the support for macvtab will be removed. Why is that so ? I have a lot of vm’s running on macvtab.

Kind regards

Marcel (Smooky)

1 Like

This is what I could locate about macvtap:

This has been broken because of other changes on the network scripts and
since we now have support for bridges there is no point in supporting
something else that has the same functionality.

EDIT: Maybe Zone Configuration will help:

Hi all.

This is a pity. In my experience, I achieve a slightly higher throughput with macvtap with a lower CPU load than in bridge mode.

Marcel (Smooky)

1 Like

Could someone please provide a basic procedure for changing from macvtap to bridge mode, including reconfiguring VMs?

I just tried and am now stuck without a working green network. Even after removing bridge configuration and re-running setup on the console to fix nic assignment i still have no network

Well that was a painful evening. My IPfire backups did not contain the /var/ipfire directory so I couldn’t find my previous network to MAC assignments!

(EDIT: I had included a custom path /root in my backups and despite file permissions being fine the backup was failing on a sub-directory and never got through to /var/ipfire. Regardless I see that /var/ipfire/ethernet/settings was excluded by default anyway! So a backup wouldn’t have helped)

I’ve now got everything back working how it was with macvtap. I’d really appreciate it if someone could please provide a basic procedure as I asked my last post. I’m not brave to try this again until I have an idea of the correct order.

At least I now have my network to MAC assignments on paper!

As @smooky points out, there may be good technical reasons to retain macvtap support anyway. I’ve read what he says elsewhere.

1 Like

Broken, as in you define a green zone and orange zone with macvtap, save it, reboot and go back to the gui screen it all a jumbled mess, my red zone is displayed as a different eth number interface as do my blue zone. the orange zone has macvtap but no interface connected to it anymore… I got really confused.

1 Like

Not sure if this helps, but I once had similar “interface connection confusing issues”, but not related the your macvtab.

What I discovered was that mt RED interface in the “Zone Configuration” was showing NONE NONE NONE for my cards, whereas the GREEN and BLUE where correctly pointing to their appropriate interface, and showing NATIVE.

When I changed the RED to point to its appropriate interface, I lost all conectivity to the internet.

So as it turns out, my issue was that I had assigned a different pseudo mac address on the gui “Network → Assign Mac Address” , which was not showing up on the “Zone Configuration” menu. May or may not be related to your issue, but may be worth taking a look.

Thanks, but I think what @trixwood and I have seen is a combination of things and possible a bug.

I previously assigned a custom MAC address to my RED interface, however I have since removed this. The “Zone Configuration” UI currently shows RED (eth0) as having a different MAC to the custom MAC and the built-in MAC! It’s an address I’ve never set and which doesn’t match the Intel NICs I have! It also shows GREEN as having MacVTap configured but no assigned NIC?
I think I’ll just stick to the configuraiotn file and skip the UI. It seems I may also have to try the change again in two steps. The first to reboot without macvtap and the second to add bridging.

My IPFire computer has 4 NICs and all are used (RED + ORANGE + BLUE + GREEN) and there are no additional NIC MACs I could be getting confused (not even WiFI ones).

If you think you have a bug then please raise a bug report in the IPFire bugzilla

Your IPFire Community email address and password will log you in to bugzilla.

Raising a bug records it in the IPFire system and iafter review, if confirmed, will have someone assigned to it. You can also then track any progress etc on that bug.

See the wiki page on bugzilla

@bonnietwin It’s very easy to say that, but not very helpful.

If the developers have decided to remove a feature people are using (because they don’t have the time to maintain two methods), why would they look in to a bug related to unconfiguring the samed deprecated feature?

I thought you were saying you had a bug trying to make bridging do what you used to do with macvtap. That would be a bug.

If your bug is that macvtap is no longer available then don’t raise a bug.

@bonnietwin It seems that you didn’t understand my post before you sent your message about posting a bug report.

I said that if there is a bug, it is related to network configuration and assignment when removing ‘macvtap’ configuration. It may be related to setting a custom MAC but seems to happen even when that has been un-configured.

As an aside, I’m not sure if it was you but I found it very unhelpful that my other thread on this topic was closed (after it was linked to this one). I would have liked the ability to reply before that thread was closed. For the record I raised that other thread after searching for ‘macvtap’ but at the time I posted this thread must not have been indexed by search yet. There were no hits for ‘macvtap’ at that time.

Anyway, I’m annoyed that we only have a short time to switch to Bridging and that it seems that no consideration has been made that bridging and macvtap may not be identical when it comes to resource usage.

@rejjysail Only the gui was a mess, probably due to the macvtaps have different mac addresses then the original eth interfaces, the actual configuration was correctly saved and working. Appears to be a gui bug thing.

So maybe there is a bug in the zone gui handling mac addresses of interfaces of not directly assigned to physical hardware???

@dnl switches last night to bridge instead of macvtap (now also my zones are correctly displayed again ;). In anticipation of the change. And tested my vm’s. The only difficulty I encountered was that a couple of vm running debian 10 with the default dhclient would not connect at all, no idea why, but the vm’s using dhcpcd functioned. So changing to dhcpcd and adding “option routers” to the config file fixed it.

What I did was, I set up the zone config in the gui to use bridges saved it. Rebooted. Then run setup from the console because of the mess, to get to a basic state and reassign the physical nics to the right zones.

Which were again a mess… seems changing from macvtap to bridges in the gui ipfire does not like it… it gets confused…

Changed the vm’s to use the bridges instead of the macvtaps… all running smootly…

1 Like

Yes, I think that the zone config gui is a bit out of touch with what goes on in the setup config side.

Thanks @trixwood and @rejjysail
When I have time next I’m going to go back to a standard network configuration (no macvtap and no bridging). Then I’ll try to configure bridging.

Thanks for the tip about Debian - I do have a debian VM hosted on IPfire.

Since update 156 was released I was motivated to finally fix this.

In case anyone else has an old macvtap configuration, I recommend removing that configuration then rebooting, then enabling bridging and rebooting again. Then you can reconfigure your virtual machines.

When removing the macvtap configuration you should edit the /var/ipfire/ethernet/settings file - do not use the zone GUI as it will fail (even before update 156).