@JonathanLee This is solved, somehow, I don't remember...just noting the thread can be closed.

Just in case anyone find this thread, i did a better article:

pfSense on TrueNAS Scale KVM, What is the best Virtual Custom CPU to choose? | QuantumWarp

https://forum.proxmox.com/threads/dhcp-on-pfsense-vm-not-handing-out-addresses-past-the-host.102763/

Seems like I'm not the only one..

To bad it's Intel driver "igc" that is the problem.. i226-LM and i226-V is having the same problem and i even think i saw i225..

@saluteferux said in Help with High CPU Usage in OPNSense/Pfsense VM inside Proxmox:

and using additional bridges to assign an IP on the proxmox host

If any of those bridges are connected in Promox to any of the I226-V NICs then you are not using pass through of the I226-V.

Pass through is done via Proxmox GUI -> pve -> VM -> Hardware -> Add -> PCI device Virtual switches / bridges via Proxmox GUI -> pve ->Network-> create (to create a virtual switch), then Proxmox GUI -> pve -> VM -> Network device -> Add (to plug the VM into the virtual switch).

But I assume you already knew this & I'm just not understanding what you are saying.

As for why there is a difference between VM load inside a VM compared to the Load measure outside the VM by the hypervisor, I believe the difference is overhead (including task switching, virtual device emulation, interrupt pre processing etc)

@johnpoz Oki

@kevdog If you're using ZFS then it might be the ZFS cache. 8G seems like a lot for pfSense btw unless you're running every service under the Sun.

@GPz1100 said in pfsense vtnet lack of queues:

@chrcoluk Any progress/movement on the vtnet queues issue?

It was declined, if I remember right they said it was too difficult to do, because it required a recompile instead of a loader flag change.

Just ran across this on one of my firewall appliances.

Approaching the limit on PV entries, consider increasing either the vm.pmap.shpgperproc or the vm.pmap.pv_entries tunable.

What exactly is a "PV" entry? No one said.

This firewall has been running for 840 days and just started dropping some phonecalls for the site this week, so i am just going to reboot it and see if this error goes away. But it would be interesting to know what exactly this error message indicates. What can cause this behaviour?

From this article here: https://supportportal.juniper.net/s/article/EX2300-C-printing-logs-Approaching-the-limit-on-PV-entries?language=en_US

Seems to have something to do with virtual memory.

On the kernel, each virtual address which is mapped to a given dynamically-allocated physical memory page uses up one pv_entry in the kernel, which contains information about that specific virtual translation. The kernel imposes a max limit on the number of pv entries that can be allocated on the system.

This message means the system is running low on pv entries in the kernel,

will post back if rebooting fixes it.

device is an SG-3100 running 21.05.2-RELEASE

@billsecond said in PfSense + Hyper-V + VLANs:

Get-VMNetworkAdapter -VMName "lab1-pfsense" | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "1-2048" -NativeVlanId 90

Hi, please any one can help me to reverse this command?
I mess up my connection with these powershell:
Get-VMNetworkAdapter -VMName "PfSense-home" | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "1-2048" -NativeVlanId 1030
PS C:\Windows\system32> Get-VMNetworkAdapter -VMName "PfSense-home" | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "1-2048" -NativeVlanId 1031
PS C:\Windows\system32> Get-VMNetworkAdapter -VMName "PfSense-home" | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "1-2048" -NativeVlanId 1032
PS C:\Windows\system32> Get-VMNetworkAdapter -VMName "PfSense-home" | Set-VMNetworkAdapterVlan -Trunk -AllowedVlanIdList "1-2048" -NativeVlanId 1033

After RTFM I was able to stop the Intel i40en driver from disabling trusted mode on the virtual functions on every reboot, but that didn't resolve the error message. The good news is now the firewall doesn't come up from a boot in a broken state every time, but this confirms the AQ returned error VIRTCHNL_ERR_PARAM to our request CONFIG_RSS_KEY! error is unrelated to the i40en driver's handling of trusted mode.

Anyone else have any brilliant ideas for what could be causing the error message?

Anyone have any guess as to whether it can safely be ignored? It doesn't stop pfSense from passing traffic on the NIC so it seems to "work," but God forbid it's creating some sort of security vulnerability!