Bug #4401
closed
remove xen netfront driver until it can handle altq
Added by Grischa Zengel about 9 years ago. Updated over 8 years ago.
0%
Description
Since 2.2 (freeBSD 10.1) pfsense always detect xen on booting and uses pv(hvm) drivers (xn#).
xn0 is unusable without traffic shaping and tagging.
There is no way to go back to use emulated NICs (em#), because xen_platform_pci=0 will produce kernel panic.
This bug is related to #4345.
Updated by Ermal Luçi about 9 years ago
XN driver does not support ALTQ at all though it should not be hard to implement it.
Updated by Chris Linstruth about 9 years ago
xn0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
options=3<RXCSUM,TXCSUM>
ether be:f5:19:d5:81:bb
inet 172.26.0.1 netmask 0xffffff00 broadcast 172.26.0.255
inet6 fe80::bcf5:19ff:fed5:81bb%xn0 prefixlen 64 scopeid 0x5
nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
media: Ethernet manual
status: active
No altq, no vlans.
Updated by Grischa Zengel about 9 years ago
Is there a way to disable xen detection while booting?
I had to remove traffic shaping from my local pfsense and now we are unable to work properly.
If there is no quick solution I have to use bare metal.
I can not update our cloud servers, because each have a virtual pfsense and are chained in vlans.
Updated by Chris Buechler about 9 years ago
- Status changed from New to Rejected
We will get ALTQ support into xn for 2.2.2. We'll track that on the original ticket for that problem, #4345
We're not going to remove xn. A slew of people upgraded Xen VMs to 2.2 and updated their configurations accordingly. Traffic shaping is a minority.
We're not going to break the significant majority for the needs of the minority. If you must have ALTQ traffic shaping in Xen, you'll have to stick with 2.1.5 for the moment. Many circumstances can be accommodated with limiters rather than ALTQ, and limiters will work fine in Xen with 2.2.
Updated by Grischa Zengel about 9 years ago
If it's come with 2.2.2 I can wait.
But if not I think 100% update success is better than 80% faster running systems and 20% waste.
The most systems I use have traffic shaping because of VoIP and other time critical services (RDP, VNC, SQL, ...).
If I understand cmb right in his post pfsense shouldn't never use xn, because it's not xen which change things it's pfsense:
https://forum.pfsense.org/index.php?topic=84255.msg462150#msg462150
Where is the source code for the changes?
Updated by Chris Buechler about 9 years ago
Removing this would not result in 100% upgrade success, it'd result in 100% of already upgraded and fixed systems breaking when upgrading 2.2 to 2.2.1, then 100% breaking again going from 2.2.1 to 2.2.2. That's unacceptable. The big warning in the upgrade guide is there for Xen users, who should have all noted that and changed things in the process.
My post in that linked thread (I'm cmb) is opposite what you said. It's Xen's stupid behavior of changing your NIC type out from under you without any ability to control what it's presenting the OS at the root of this issue.
The source in question that makes Xen do this is in stock FreeBSD 10.1. You can remove that from the kernel config and build your own kernel. That's in tools, details for reaching it here:
https://forum.pfsense.org/index.php?topic=76132.0
Updated by Grischa Zengel about 9 years ago
You make a really good job and if XN+ALTQ is working in 2.2.2 we'll never spoke about that.
It's never xen which changes the NIC. From first days on xen gives the DomU the ability to choose the right NIC and pfsense chooses the wrong one since 2.2.
It would be better not to integrate netfront until it supports ALTQ. But now it's integrated and to remove it and integrate it again with 2.2.2 is unnecessary.
Perhaps for good will you can create an unofficial release without netfront. If you have an early 2.2.2 for testing ALTQ I would test it.
Updated by Andreas Pflug over 8 years ago
2.2.4 running, still no ALTQ...
I don't see any traffic on freebsd-xen@freebsd.org about xn, so it appears that we can't expect it to be fixed in some near or mid future.
Updated by Andreas Pflug over 8 years ago
I've been told that there has been posted a patch that will give us the switch we need:
https://svnweb.freebsd.org/base?view=revision&revision=286999
xen: allow disabling PV disks and nics
I'd love this to be included in the next 2.2.5 release.
Updated by Jim Thompson over 8 years ago
- Assignee set to Renato Botelho
- Target version set to 2.3
Updated by Chris Buechler over 8 years ago
- Target version deleted (
2.3) - Affected Version deleted (
2.2)
Guessing Jim re-assigned target and to Renato to get 286999 implemented. Rejected is a closed status, so this won't show. Subject and original topic isn't happening, so I opened #5452 to cover 286999.